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ABSTRACT 


Acoustic  shallow-water  data  communications  are  unreliable.  Repeated  retransmission 
of  a  message  received  incorrectly  often  results  in  transmitter  failure  due  to  battery 
depletion.  Internet  connectivity  to  underwater  entities  via  current  network  protocols  does 
not  exist,  since  most  research  in  data  communications  has  been  focused  on  the  physical 
layer  and  the  underwater  channel  itself.  Therefore,  the  problems  addressed  by  this  thesis 
are  to  find  a  way  to  increase  the  reliability  of  underwater  data  communications,  as  well  as 
to  specify  the  steps  which  need  to  be  taken  to  enable  Internet  Protocol  (IP)  packets  to  be 
transmitted  over  an  underwater  channel. 

The  approach  taken  was  to  add  a  Hamming  forward  error-detection  and  error- 
correction  code  to  messages,  thereby  reducing  the  need  for  retransmission.  This  code  was 
implemented  in  a  PC-based  communications  system  which  uses  commercially  available 
diver’s  communication  and  navigation  devices  as  acoustic  modems.  In  a  related  effort,  the 
Internet  Protocol  stack  was  analyzed  for  areas  which  required  modification  to  enable  IP  to 
be  reliably  passed  over  an  acoustic  channel.  The  results  are  a  low-cost  reliable  underwater 
data  communications  system  which  can  easily  be  implemented  in  an  AUV  or  underwater 
sensor,  as  well  as  recommendations  for  improved  protocols  required  to  realize  true  network 
communications  in  an  underwater  environment. 
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1.  INTRODUCTION 


A.  PURPOSE 

The  purpose  of  this  work  is  to  describe  the  current  state  of  underwater  data 
communications,  demonstrate  how  underwater  communications  reliability  can  be  greatly 
improved  using  forward  error  correction  and  to  outline  the  work  required  to  ultimately  pass 
Internet  Protocol  (IP)  datagrams  between  two  or  more  computers  connected  by  an  acoustic 
underwater  channel. 

B.  MOTIVATION 

Motivation  for  this  study  arises  out  of  the  author’s  interest  in  diving,  underwater 
exploration  and  marine  salvage.  One  of  a  diving  supervisor’s  largest  headaches  is  keeping 
track  of  a  number  of  scuba  divers  in  the  water,  since  there  are  few  ways  of  communicating 
with  them  as  they  work.  One  method  is  with  underwater  speaking  units  which  transmit  the 
diver’s  speech  to  other  divers  or  to  the  surface  by  modulating  speech  onto  an  acoustic 
carrier  wave.  Such  units  require  modifications  to  the  breathing  regulator  to  afford 
movement  of  the  mouth,  and  often  transmit  breathing  noises  which  interferes  with  speech. 
They  also  do  not  provide  location  data  to  either  the  diver  or  the  surface,  other  than  where 
the  diver  says  they  are,  which  is  not  always  accurate.  The  other  method  is  with  a  safety  line 
using  pull  signals,  which  indeed  provides  positive  control,  but  requires  line  tending  and 
often  results  in  tangled  safety  lines  if  multiple  divers  are  deployed.  Keeping  track  of 
underwater  divers,  more  than  any  other  problem,  provided  the  spark  to  ignite  an  interest  in 
acoustic  data  communication.  The  hardware  which  was  able  to  solve  the  diver 
communication  problem  was  also  easily  applied  to  much  more  significant  problems  in 
computer  networking:  restructuring  existing  acoustic  protocols  for  reliability,  and 
providing  IP  compatibility.  The  importance  of  these  critical  issues  has  not  been  previously 
recognized. 
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The  hardware  used  in  this  thesis  was  originally  designed  for  use  as  a  diver 
communication  and  navigation  device.  Due  to  the  user-configurable  architecture  of  the 
hardware,  it  was  quickly  apparent  that  there  were  applications  that  it  could  be  applied  to 
that  were  much  more  complicated  and  closer  aligned  with  computer  science  than  simply 
communicating  with  divers.  The  study  of  networks  and  implementing  them  is  the  future  of 
computer  science.  Connecting  people,  places  and  things  in  whatever  environment  they 
exist  is  quickly  becoming  a  reality.  The  underwater  environment  is  the  final  frontier  in  that 
exploration.  The  goal  of  extending  the  Internet  underwater  is  a  goal  that,  if  realized,  will 
facilitate  great  strides  in  underwater  exploration  and  autonomous  vehicular  control. 

There  is  another  aspect  to  this  work  as  weU.  Currently  the  size  of  the  physical  Internet 
and  the  corresponding  volume  of  information  content  in  the  World-Wide  Web  (WWW)  are 
growing  at  long-term  sustained  rates  of  15  and  20  percent  per  month,  respectively.  The 
importance  of  gaining  Internet  connectivity  to  underwater  devices  for  science,  exploration, 
and  collaborative  research  is  undeniable.  The  potential  benefits  stemming  from  acoustic 
communications  compatibility  with  IP  are  overwhelmingly  valuable  [Brutzman  94]. 

C.  OVERVIEW 

This  thesis  unites  three  separate,  diverse  and  interrelated  fields:  underwater  acoustics, 
network  protocol  theory,  and  error-correcting  codes.  Each  of  these  areas  has  a  rich  history 
which  must  be  appreciated  in  order  to  see  what  the  research  described  in  this  thesis  is 
attempting  to  do. 

D.  CHAPTER  LAYOUT 

The  diversity  of  interrelated  material  covered  in  this  thesis  has  been  carefully 
structured  to  emphasize  clarity.  Chapter  II  discusses  background  information  and  previous 
work  pertaining  to  computer  communication,  networking  and  underwater  acoustics. 
Chapter  III  describes  the  problems  encountered  in  acoustic  data  communication.  Chapter 
IV  outlines  error  correction  codes:  how  they  work,  what  they  are  used  for,  and  (especially), 
how  they  apply  to  acoustic  channels.  Chapter  V  describes  the  TCP/IP  protocol  stack  and 
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how  it  applies  to  Internet-compatible  communications.  Chapter  VI  documents  the 
experimental  setup  used  and  experimental  results  obtained.  Conclusions  and 
recommendations  for  future  work  are  expressed  in  Chapter  Vn.  Code  written  for  this  thesis 
and  sources  for  proprietary  code  are  listed  in  Appendix  A.  A  guide  to  programming  the 
DiveTracker  communication/navigation  devices  is  presented  in  Appendix  B.  Appendix  C 
is  a  list  of  acronyms  used  in  this  thesis  with  their  English  equivalents.  A  tutorial  on  setting 
up  Arlan  620  and  Airlan  RF  Ethernet  Bridges  is  presented  in  Appendix  D.  Finally, 
Appendix  E  provides  information  pertaining  to  electronic  retrieval  of  this  thesis  and 
supporting  code. 
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IL  BACKGROUND  AND  RELATED  WORK 


The  subject  of  sound  in  the  ocean  encompasses  many  areas  of  research,  from  biologists 
studying  whales  and  dolphins,  to  meteorologists  trying  to  determine  ocean  temperature,  to 
naval  officers  trying  to  locate  a  submarine  which  is  thought  to  be  in  the  operating  area.  The 
fact  that  sound  travels  in  water  farther  than  in  air  is  not  new,  but  there  are  many  scientific 
and  technological  breakthroughs  in  signal  processing  which  have  occurred  recently  to 
almost  make  sound  in  the  ocean  a  completely  new  area  of  study.  In  addition  to  the 
improvements  and  standardization  of  computer  communications,  digital  communications 
through  water  is  now  a  reality.  However,  water  is  not  a  perfect  channel,  nor  does  it  lend 
itself  easily  to  passing  digital  data  at  high  speeds,  which  is  the  goal  of  modem  computer 
networks.  The  following  sections  provide  background  in  underwater  acoustics  and 
computer  network  theory.  Recent  improvements  in  hardware  are  described  and  compared. 
In  addition,  current  documented  work  in  the  area  of  acoustic  communications  is  reported 
in  an  attempt  to  define  the  state  of  the  art  of  acoustic  data  communications. 

There  are  significant  applications  for  which  underwater  data  communications  are 
necessary.  Data  collection  stations,  such  as  those  described  for  a  Autonomous 
Oceanographic  Sampling  Network  (AOSN)  [Curtin  93]  and  the  Modular  Abyssal  Benthic 
Laboratory  (MABEL)  [Luther  94]  plan  to  rely  on  acoustic  data  links  to  transfer  data 
between  submerged  network  nodes  and  to  direct  Autonomous  Underwater  Vehicles 
(AUVs)  piloting  through  the  area.  These  data  collection  stations  perform  current  sampling, 
salinity  and  temperature  to  help  solve  frontal  dynamics  problems  which  are  at  present 
highly  dependent  on  limited  platform  (research  vessel)  availability.  Other  applications 
might  involve  teams  of  AUVs  which  are  tasked  with  searching  an  area  for  mines  and 
require  the  individual  units  to  communicate  among  themselves  to  localize  targets,  provide 
collision  avoidance,  or  communicate  with  an  assist  vessel  on  the  surface.  Although  these 
applications  may  not  sound  much  like  a  computer  network,  the  communications 
networking  requirements  here  are  as  applicable  as  in  terrestrial  systems. 
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A.  COMPUTER  COMMUNICATION 

It  is  expected  that  the  reader  of  this  thesis  akeady  has  or  will  obtain  some  knowledge 
of  computer  communications.  The  objective  of  the  sections  to  follow  is  to  generalize  the 
aspects  of  data  communications  common  to  all  networks  which  specifically  apply  to 
underwater  acoustic  communications.  This  will  be  done  by  approaching  the  relationship 
between  a  computer  and  its  network  hardware,  and  then  describing  how  the  hardware 
actually  uses  the  medium  over  which  it  communicates.  The  physical  medium  is  the  point 
at  which  underwater  acoustic  communications  diverges  from  common  communications 
media.  The  physical  medium  is  also  the  realm  of  acoustic  modems  which  are  tasked  with 

the  job  of  actual  data  transmission  through  the  water. 

A  great  deal  of  the  insight  into  network  communications  was  gained  by  the  author 
through  the  installation  of  the  LINUX  operating  system  on  a  IBM-compatible  personal 
computer  (PC).  From  the  first  steps  of  reformatting  the  hard  drive  to  accept  an  additional 
operating  system  to  the  actual  compiling  the  operating  system  kernel,  every  step  was 
outlined  in  articulate  How-To  manuals  and  concise  walk-throughs.  This  experience  is 
highly  recommended  for  anyone  desiring  a  deeper  understanding  of  computer 
communication,  operating  systems,  and  those  tired  of  what  Microsoft  or  IBM  have  to  offer 
in  32-bit  operating  systems.  Most  useful  was  the  time  spent  on  network  configuration  and 
setup.  This  process  cements  the  theory  learned  in  the  classroom  into  practical  reality.  More 
information  can  be  found  at  [University  of  Helsinki]. 

Computers  communicate  with  one  another  by  utilizing  networks,  structures  comprised 
of  as  few  as  two  to  many  links  of  various  communication  media.  The  media  is  the  physical 
substance  or  material  utilized  to  pass  the  computer  signals  over  or  through,  and  the  signals 
are  tailored  for  that  particular  medium.  For  example,  networks  that  use  fiber  optic  cable 
have  circuitry  and  hardware  devices  to  change  the  electrical  signals  the  computer  generates 
into  light  energy,  since  the  fiber-optic  cable  transmits  light  rather  than  electrical  energy. 
Likewise,  twisted  pair  networks  utilize  wire  not  much  different  than  standard  telephone 
line,  but  must  use  specialized  circuitry  in  each  of  the  networked  computers  to  convert  the 
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digital  signals  generated  by  the  computer  into  specific  voltages  and  timed  pulses  that 
conform  to  what  the  other  computers  expect  to  see  on  the  line.  This  lowest  layer  is  termed 
the  physical  layer,  and  it  has  four  important  characteristics:  mechanical,  electrical, 
functional  and  procedural  [Stallings  94]. 

The  mechanical  characteristics  describe  the  physical  connections  that  must  be  made 
between  a  computer  and  the  network  communication  equipment,  such  as  that  between  a 
computer  and  an  external  modem  for  communication  over  a  telephone  line,  or  between  a 
computer  and  a  network  interface  card  (NIC)  for  communication  over  a  local  area  network 
(LAN).  This  is  usually  described  in  a  standardized  connector  format,  such  as  a  9-pin 
connector  or  a  DB-25  pin  connector,  each  having  certain  pin  numbers  and  purposes  which 
are  agreed  upon  through  a  common  standard. 

Electrical  characteristics  define  voltage  levels  and  timing  of  signals.  Both  the 
computer  and  the  network  equipment  must  use  the  same  code,  or  conrununication  will  not 
occur  properly.  In  other  words,  both  the  data  terminal  equipment  (DTE)  and  data 
communication  equipment  (DCE)  must  be  “reading  the  same  sheet  of  music.”  The 
computer  is  labeled  the  data  terminal  equipment,  since  it  is  the  source  or  terminus  of  the 
signals  to  be  sent,  and  the  network  hardware  (modem,  network  card,  etc.)  is  the  data 
communication  equipment,  as  it  actually  performs  the  “communication”  using  the  network 
medium. 

Functional  characteristics  define  the  functions  performed  by  the  various  circuits 
comprising  the  connections  between  the  DTE  and  the  DCE.  These  are  usually  categories 
such  as  data,  timing,  control,  and  signal  ground. 

Finally,  procedural  characteristics  define  a  sequence  of  events  to  communicate  the  data, 
tailored  to  the  functional  characteristics  specified  above. 

Standards  introduced  to  completely  detail  these  characteristics  of  a  physical  layer  allow 
different  manufacturers  to  build  compatible  components,  so  that  products  from  completely 
separate  sources  can  reliably  and  easily  communicate.  An  example  of  this  type  of  standard 
is  the  Recommended  Standard  Number  232,  Revision  C,  from  the  Engineering  Department 
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of  the  Electronics  Industries  Association,  known  as  EIA  RS-232C,  or  simply  RS-232.  The 
RS-232C  standard  sharply  divides  its  functions  into  data  functions  and  control  functions. 
The  data  functions  are  assigned  to  the  transmitter  and  receiver  on  pins  2  and  3,  respectively. 
These  are  the  only  two  pins  through  which  data  flows.  AU  the  remaining  23  pins  of  the 
standard  DB-25  serial  plug  are  control  functions,  so  named  because  they  carry  the  status  or 
command  for  controlling  a  serial  device’s  behavior.  Additional  details  of  RS-232  are 
detailed  in  [Campbell  87]  and  [Stallings  94].  An  excellent  hypertext  discussion  of  RS-232 
and  modems  is  [Zinzow  94].  Another  very  good  discussion  of  serial  port  communications 
is  [Blum  95].  It  must  be  made  clear  that  the  foregoing  discussion  of  the  physical  layer 
describes  the  interface  between  the  computer  equipment  and  the  communication  equipment 
(DTE  to  DCE).  It  does  not  describe  the  communication  which  occurs  between 
communication  equipment  via  the  network  medium  (DCE  to  DCE).  Communication 
between  DCEs  is  specifically  designed  to  take  advantage  of  the  physical  characteristics  of 
the  medium,  whether  it  be  the  atmosphere,  space,  copper  electrical  cable,  fiber  optic  cable, 
or  water.  Figure  II-l  shows  the  relationship  among  these  various  components. 

The  serial  port  accepts  bytes  from  the  CPU  data  bus  and  passes  bits  to  the  modem.  In 
doing  this,  the  serial  port  can  add  or  delete  bits,  depending  on  the  coding  scheme  in  use.  At 
(1)  the  concern  is  with  bytes  per  second.  At  (2)  the  concern  is  with  bits  per  second,  and  at 
(3)  the  concern  is  with  Baud  (signal  changes  per  second).  The  difference  is  due  to  the  fact 
that  the  number  of  bits  at  (2)  need  not  be  equal  to  the  number  of  bits  (that  is,  bytes  times  8) 
at  (1),  and  the  number  of  state  changes  at  (3)  is  not  necessarily  the  same  as  the  number  of 
bits  at  (1)  or  (2).  Bits  can  be  stripped  going  from  (1)  to  (2):  the  serial  port  may  transmit  only 
6  or  7  of  the  8  bits  in  the  byte.  Bits  can  be  added  going  from  (1)  to  (2):  the  serial  port  can 
add  a  parity  bit  and  stop  bits. 

Various  methods  are  used  to  exploit  the  medium  and  carry  data  through  it.  For 
example,  in  terrestrial  microwave  communications,  electromagnetic  waves  of  a  frequency 
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between  1  and  18  GHz  are  used  to  carry  the  encoded  data  from  one  microwave  station  to 


Figure  U-1:  Serial  communications  channel  [Blum  95]. 

another.  The  method  used  to  actually  encode  the  data  with  the  RF  energy  data  is  usually 
modulation.  Modulation  is  the  process  of  encoding  source  data  onto  a  carrier  signal  that  is 
compatible  with  the  transmission  media.  From  (2)  to  (3),  bits  may  be  clustered  to  groups 
that  are  transmitted  using  different  encoding  schemes  like  Frequency  Shift  Keying  (FSK) 
or  Quadrature  Amplitude  Modulation  (QAM).  Methods  used  to  carry  data  over  water  will 
be  explained  in  more  detail. 

1.  Communications  Media 

Data  communication  systems  in  use  today  utilize  various  media  over  which  they 
establish  and  maintain  connections  between  individual  components  and  networks. 
Common  media  (and  their  connections)  include  the  following: 

•  Twisted-pair  cable  (lOBaseT) 

•  Coaxial  cable  (10Base2,  lOBaseS) 

•  Fiber  Optic  cable  (FDDI,  lOBaseF) 

•  Microwave  radio  frequencies  (Terrestrial  and  Satellite  communications,  and 
microwave  LAN  bridges) 
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I 

*  Very  High  Frequency  (VHF)  and  Ultra  High  Frequency  (UHF)  radio  (packet 
radio) 

♦  To  some  extent,  water 

Each  of  the  above  media  (with  the  exception  of  water)  have  been  exhaustively 
researched  and  exploited  in  order  to  achieve  the  highest  possible  data  transfer  rates  and 
reliability  possible  using  current  technology.  Protocols  are  agreed-upon  sequences  of  data 
exchange  that  are  used  between  communicating  entities  over  each  media.  Typically 
protocols  are  optimized  to  take  advantage  of  the  electrical  and  physical  characteristics  of 
the  media  itself  and  the  type  of  data  that  is  to  be  communicated.  Common  media  and 
protocols  usually  run  on  them  are  listed  in  Table  11-1. 


MEDIA 

PROTOCOL 

Twisted-Pair  (lOBaseT 

Ethernet,  Token  Ring 

Coaxial  Cable 

Ethernet,  Token  Ring,  Token 
Bus 

Fiber-optic  Cable 

Token  Bus,  FDDI,  DQDB 

Microwave  RF 

Ethernet,  Token  Ring 

Water 

???? 

Table  II-l:  Communications  media  and  common  protocols. 


Networks  today  cover  areas  ranging  from  a  single  room  in  a  school  or  business  to 
hundreds  of  square  miles,  as  in  the  case  of  wide-area  network  (WANs)  and 
metropolitan-area  networks  (MANs).  The  entire  group  of  interconnected  networked 
computers,  servers,  routers,  and  hosts  in  academic  institutions,  commercial  businesses,  and 
homes  all  over  the  world  is  called  the  Internet.  It  is  actually  a  network  of  networks  and 
utilizes  all  of  the  media  listed  above.  It  is  possible  to  easily  connect  almost  anything  to 
anything  with  the  glaring  exception  of  entities  which  operate  autonomously  in  water. 


B.  HIGHER  LEVEL  NETWORKING 

The  preceding  section  describes  the  communication  a  computer  has  with  its  network 
hardware.  That  was  a  “middle-down’  approach.  This  section  describes  a  “middle-up” 
approach  to  communication.  Data,  in  the  form  of  electrical  digital  signals,  travels  through 
a  series  of  “layers”  from  the  user  application  to  the  actual  point  the  computer  communicates 
with  the  network.  One  of  the  most  common  models  of  internet  communication,  the 
Transport  Control  Protocol/Intemet  Protocol  (TCP/IP),  is  described  by  Figure  II-2, 
showing  a  basic  gateway  (or  Internet  Protocol  (IP)  module)  associated  with  each  Transport 
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Higher  Level  Applications 
(email,  FTP,  telnet) 

Transport  Control  Protocol 
(TCP) 


Internet  Protocol  (IP) 

Communication  Network 
Layers  (ethemet,  FDDI, 
serial  port) 


t 

t 

t 


Layers  traversed  by  data  Layers  traversed  by  data 

leaving  one  host  enroute  to  entering  host  from  a  remote 

another  host  host 


Figure  II-2:  TCP/IP  protocol  layering. 


Control  Protocol  (TCP)  packet  which  provides  an  interface  to  the  local  network.  A  basic 
“gateway”  packages  TCP  segments  inside  Internet  datagrams  using  IP  and  routes  these 
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datagrams  to  a  destination  or  intermediate  gateway.  To  transmit  the  datagram  through  the 
local  network,  it  is  embedded  in  a  local  network  packet,  such  as  an  Ethernet  packet.  The 
packet  switches  at  the  network  level  may  perform  further  packaging,  fragmentation,  or 
other  operations  to  achieve  the  delivery  of  the  local  packet  to  the  destination  gateway.  At  a 
gateway  between  networks,  the  IP  datagram  is  “unwrapped”  from  its  local  packet  and 
examined  to  determine  through  which  network  the  Internet  datagram  should  travel  next. 
The  IP  datagram  is  then  “wrapped”  in  a  local  packet  suitable  to  the  next  network  and  routed 
to  the  next  gateway.  A  gateway  is  permitted  to  break  up  a  datagram  mto  smaller  datagram 
fragments  if  this  is  necessary  for  transmission  through  the  network.  To  do  this,  the  gateway 
produces  a  set  of  datagrams,  each  carrying  a  fragment.  Fragments  may  be  broken  mto 
smaUer  ones  at  intermediate  gateways.  The  IP  datagram  fragment  format  is  designed  so  that 
the  destination  gateway  can  reassemble  fragments  into  Internet  datagrams.  A  destination 
gateway  unwraps  the  segment  from  the  datagram  (after  reassembling  the  datagram,  if 
necessary)  and  passes  it  to  the  destination  TCP.  An  example  of  this  communication 
between  two  hosts  through  the  network  is  shown  in  Figure  II-3. 

Each  of  the  layers  in  the  TCP/IP  stack  have  specific  functions  which  the  software  and 
hardware  at  that  level  is  expected  to  accomplish.  Furthermore,  each  layer  has  a  set 
“appearance”  to  layers  above  and  below  it,  so  that  communications  with  each  layer  take 
place  according  to  agreed-upon  mles  ox  protocols.  Functions  performed  by  each  layer  are 
outlined  in  Figure  II-4.  Request  For  Comments  (RFC)  791  [Postel  81]  is  the  “bible”  of  the 
Internet  Protocol,  and  should  be  referred  to  for  datagram  format  and  protocol  operation.  An 
outstanding  tutorial  on  the  Internet  Protocols  is  found  in  [Hednck  87]. 

The  TCP/IP  model  is  not  the  only  model  of  communications,  however.  The  Open 
Systems  Interface  (OSI)  model  of  the  International  Standards  Organization  (ISO)  also  has 
layers  which  are  characterized  by  various  protocols  which  pass  data  from  one  layer  to 
another,  starting  at  the  bottom  in  the  physical  layer  with  the  actual  transmission  of  the  Is 
and  Os  over  the  media.  This  layer  interacts  closely  with  the  network  layer  to  ensure 
error-free  transmission  and  receipt  of  groups  of  bits,  called  frames,  which  are  grouped  into 
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packets,  and  given  addresses  which  are  routed  by  the  network  layer  in  either  a 
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Figure  11-3:  Internet  protocol  stack  [Brutzman  95]  [Stallings  94]. 

connectionless  protocol  or  one  which  is  connection-oriented.  The  term  connection  here 
refers  to  the  idea  of  setting  up  a  dedicated  path  between  two  or  more  participating  nodes, 
and  keeping  this  path  in  existence  until  the  data  has  been  transferred  and  acknowledged. 
Connectionless  protocols,  on  the  other  hand,  route  each  packet  independently  of  all  others 
through  the  network,  requiring  the  recipient  to  reorder  the  packets  upon  receipt.  Lost  or 
damaged  packets,  in  either  type  of  network  protocol,  are  taken  care  of  by  the  transport  layer 
in  its  job  of  providing  reliable  service  to  the  application  layer,  which  provides  the  original 
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information  to  the  network  itself.  Functions  of  each  of  the  layers  in  the  OSI  model  are 


•  Process/ Application  Layer.  Applications  invoke  TCP/IP  services,  sending 
and  receiving  messages  or  streams  with  other  hosts.  Delivery  can  be 
intermittent  or  continuous. 

•  Transport  Layer.  Provides  host-to-host  packetized  communications  between 
applications,  using  either  reliable  delivery  connection-oriented  Transmission 
Control  Protocol  (TCP)  or  unreliable  delivery  connectionless  User  Datagram 
Protocol  (UDP).  Exchanges  packets  end-to-end  with  other  hosts. 

•  Internet/Gateway  Layer.  Encapsulates  packets  in  an  IP  datagram  which 
contains  routing  information.  Receives  or  ignores  incoming  datagrams  as 
appropriate  from  other  hosts.  Checks  datagram  validity,  handles  network  error 
and  control  messages. 

•  Data  Link/Network  Physical  Layer.  Includes  physical  media  signaling  and 
lowest  hardware  functions.  Exchanges  network-specific  data  frames  with  other 
devices.  Includes  capability  to  screen  multicast  packets  by  port  number  at  the 
hardware  level. 


Figure  11-4:  Internet  Protocol  (BP)  suite  layers  [Brutzman  95]. 
presented  in  Figure  II-5. 

One  thing  that  sets  apart  the  ISO-OSI  system  is  the  extensive  error-checking  which 
goes  on  at  each  layer  of  the  process,  effectively  taking  the  data  which  is  to  be 
communicated  and  “wrapping”  it  with  a  header  from  each  underlying  layer  until  the 
message  presented  to  the  physical  layer  is  merely  a  physical  layer  header  preceding  a 
header  from  each  preceding  layer  followed  by  a  small  amount  of  code  from  the  application. 
In  other  words,  extreme  overhead  is  a  problem.  A  newcomer  to  the  scene  is  the  client-server 
model,  which  recognizes  the  ability  of  a  terrestrial  LAN  to  carry  data  at  rates  which  are 
unattainable  on  a  WAN  due  to  the  load  which  the  ISO  OSI  layers  put  on  the  network  node’s 
Central  Processing  Unit  (CPU)  while  it  labors  at  stripping  and  re-installing  header 
information  onto  a  message.  In  essence,  the  client-server  model  skips  the  network  and 
transport  layers  of  the  ISO  OSI  model  and  concerns  itself  with  only  the  application,  the  data 
link,  and  the  physical  layers  to  send  connectionless  packets  between  machines.  Remote 
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Procedure  Call  (RPC),  like  the  client-server  model,  utilizes  the  high  data  rates  achievable 

•  Physical  Layer;  responsible  for  the  mechanical  and  electrical 
interface  to  the  communications  media. 

•  Data  Link  Layer:  responsible  for  the  transmission,  framing  and 
error  control  over  a  single  communications  link. 

•  Network  Layer:  responsible  for  the  data  transfer  across  the 
network,  independent  of  both  the  media  comprising  the 
underlying  subnetworks  and  topology  of  those  sub-networks. 

•  Transport  Layer:  responsible  for  the  reliability  and 
multiplexing  of  data  transfer  across  the  network  to  the  level 
provided  by  the  application. 

•  Session  Layer;  provides  the  management  and  data  flow  control 
services. 

•  Presentation  Layer:  provide  a  common  representation  of 
application  layer  data.  Basically  responsible  for  adding 
structures  to  the  units  of  data  that  are  exchanged. 

•  Application  Layer:  layer  where  the  Goal  of  OSI  is  realized. 

Ultimately  responsible  for  managing  the  communications 
between  applications. 

Figure  II-5:  ISO  OSI  Layer  Protocol  Functions  [Stallings  95]. 

on  a  LAN,  but  does  its  work  without  the  intense  Input-Output  (10)  that  characterizes  the 
client-server  model.  RPC  was  designed  to  allow  a  process  running  on  one  machine  to  call 
a  procedure  running  on  another  machine,  and  for  all  the  work  to  be  done  at  the  operating 
system  level,  including  the  actual  movement  of  bits  from  one  host  to  another.  However, 
RPC  is  applicable  only  to  situations  where  only  one  machine  is  communicating  with 
another.  Group  communication  through  a  broadcast  medium  is  not  allowed  [Tanenbaum 
92].  Of  all  the  protocol  stacks  discussed,  the  TCP/IP  stack  is  probably  the  most  widely 
utilized  due  the  availability  of  the  Microsoft  Windows  3. 1  Windows  Socket  (WINSOCK). 
The  WINSOCK  is  a  Dynamic  Link  Library  (.DLL)  and  runs  under  Windows  3.x,  Windows 
for  Workgroups,  Windows  NT,  and  Windows  95.  It  is  the  interface  between  application 
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programs  running  on  PCs  and  the  TCP/IP  stack.  From  the  WINSOCK,  the  information 
travels  out  to  the  Internet  There  are  literally  hundreds  of  TCP/IP  internet  applications  built 
for  WINSOCK,  and  this  alone  makes  TCP/IP  protocol  compatibility  for  underwater 
acoustic  devices  a  goal  towards  which  to  work. 

C.  THE  PHYSICAL  LAYER:  UNDERWATER  ACOUSTIC  TELEMETRY 

Using  sound  in  water  has  long  been  used  for  navigation,  location,  and  communication. 
As  early  as  1490  Leonardo  da  Vinci  wrote  “If  you  cause  your  ship  to  stop,  and  place  the 
head  of  a  long  tube  in  the  water  and  place  the  outer  extremity  to  your  ear,  you  will  hear 
ships  at  a  great  distance  from  you”  [Urick  83].  This  device  evolved  into  actual  steerable 
listening  devices  mounted  on  the  hulls  of  ships,  thereby  gaining  direction  of  the  source  of 
the  sounds.  In  1827,  the  speed  of  sound  in  water  was  accurately  determined.  The  late  1800’s 
saw  the  invention  of  transducers,  devices  used  to  change  electrical  energy  into  acoustic 
energy  and  vice  versa.  The  turn  of  the  century  brought  one  of  the  first  practical  applications 
of  underwater  sound,  the  submarine  bell,  which  was  used  by  ships  to  determine  distance 
from  land  or  a  lightship  where  a  foghorn  was  installed.  By  timing  the  interval  between 
hearing  the  underwater  bell  and  the  foghorn,  they  could  determine  how  far  away  they  were 
from  the  source  of  the  signal.  Early  attempts  at  electronic  amplification  progressed  into 
ASDIC,  the  British  Navy’s  investigations  into  quartz  transducers,  and  then  into  SONAR 
(SOund  Navigation  And  Ranging),  to  the  point  where  SONAR  could  accurately  and 
dependably  be  used  to  determine  bearing  and  range  of  a  submerged  target  Higher 
frequency  sonars  became  common  in  search  and  location  applications,  due  to  the  greater 
resolution  afforded  by  the  higher  frequencies.  However,  most  of  these  applications  did  not 
involve  communication,  since  rangefinding  and  target  location  do  not  require  participation 
from  more  than  one  entity.  Not  until  the  invention  of  the  underwater  telephone  during 
WWII,  which  was  much  like  a  radio  transmitter-receiver  set,  did  actual  communications 
take  place  from  submarines  to  surface  ships  or  to  other  submarines  [Piccard  61]. 
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1.  Characteristics  of  Water 

Water  is  an  excellent  working  material  for  many  applications,  but  carrying  data,  either 
by  electromagnetic  or  acoustic  means,  is  not  an  application  that  water  handles  nearly  as 
well  as  communications  media  used  in  terrestrial  computer  networks.  Generally,  acoustic 
frequencies  ranging  from  10  to  100  kiloHertz  (kHz)  travel  quite  well  in  water  over 
considerable  distances,  up  to  perhaps  20-30  kilometers.  Some  frequencies  travel  much 
further,  even  so  far  as  to  allow  listening  stations  on  the  Western  coast  of  California  to  hear 
underwater  volcanic  eruptions  off  the  coast  of  Japan  [Piccard  61].  Although  the  acoustic 
energy  is  able  to  be  received  at  long  distances,  it  is  subject  to  many  factors  which  make  it 
less  desirable  for  the  reliable  transfer  of  data.  However,  because  light  and  electromagnetic 
transmissions  do  not  pass  through  the  water  without  tremendous  attenuation,  modulation 
of  an  acoustic  signal  is  often  the  only  means  available  for  long-range  underwater 
communication. 

Sound  typically  travels  in  seawater  at  about  1450  meters  per  second  (1600  yards  per 
second),  5  orders  of  magnitude  slower  than  the  rate  electrical  signals  travel  in  a  twisted  pair 
or  coax  cable.  This  characteristic  alone  differentiates  water  from  any  other  media  used  to 
carry  data.  Noise  is  introduced  into  the  medium  by  rain,  surface  action,  machinery, 
self-noise,  and  biologies.  Distortion  of  acoustic  signals  caused  by  frequency  dependent 
absorption  of  segments  of  the  signal  and  nonlinearities  in  the  acoustic  transducers  add  to 
the  harshness  of  the  channel.  Sound  wave  refraction  occurs  due  to  changes  in  the  speed  of 
sound  in  water,  which  is  continuously  dependent  on  variations  in  depth,  temperature  and 
salinity.  Refraction  in  turn  changes  sound  propagation  paths  which  lead  to  fading  or 
multipath  reception  which  the  receiver  must  resolve.  Multipath,  arrival  of  a  single  signal  at 
multiple  times  (due  to  parts  of  the  signal  taking  a  longer  or  shorter  path  to  the  receiver) 
produces  intersymbol  interference  (ISI)  and  can  wreak  havoc  on  a  receiver’s  ability  to 
coherently  gather  data.  Attenuation  is  caused  by  the  spherical  or  cylindrical  spreading  of 
sound  from  its  source  and  absorption  of  energy  by  the  water  in  the  form  of  heat.  Doppler 
effects  cause  frequency  shifts  of  the  signal  due  to  relative  motion  between  the  receiver  and 
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transmitter,  as  is  the  case  for  a  moving  AUV.  Noise,  distortion,  and  attenuation  necessitate 
high  power  levels  to  achieve  adequate  signal-to-noise  ratios  (SNR)  for  receipt  of  a  signal. 
In  turn,  high  transmit  power  levels  create  reverberation  which  effectively  blanks  the 
transmitter’s  ability  to  receive  for  a  short  time  following  transmission. 

Bandwidth  requirements  of  underwater  networks  and  point-to-point  applications  have 
not  yet  approached  those  of  conventional  shore-based  networks,  but  will  be  faced  with 
limits  on  the  order  of  tens  of  thousands  of  bits  per  second  (bps)  for  very  short  ranges  to 
hundreds  of  bps  at  moderate  ranges.  This  is  due  simply  to  the  fact  that  the  ocean  channel 
occupies  a  very  narrow  frequency  band  which  is  usually  only  5-10  times  as  wide  as  the 
transmitter’s  peak  signal  rate. 

[Urick  83]  provides  an  excellent  introductory  analysis  of  these  many  competing  and 
interrelated  factors.  Of  particular  note  is  that  variations  in  all  these  sound  characteristics 
can  occur  over  both  short  and  long  time  scales,  creating  what  are  called  time-varying 
channels.  In  addition,  it  is  important  to  note  that  while  these  factors  are  present  in  all 
underwater  communications  channels,  the  amount  to  which  they  have  an  effect  on  data 
throughput  depends  to  a  large  degree  on  the  orientation  of  the  channel.  Vertically  oriented 
channels  are  more  often  able  to  minimize  the  negative  effects  of  these  characteristics 
because  of  the  lack  of  bottom  and  surface  reflection,  reduced  multipath  propagation,  nearly 
perpendicular  angles  of  thermocline  penetration,  and  distances  limited  by  ocean  depth. 
Horizontal  channels,  particularly  shallow-water  channels,  have  to  deal  with  surface  and 
bottom  reflections  of  acoustic  energy,  which  destructively  interferes  with  the  transmitted 
pulse  and  causes  multipath  reception  at  the  receiver.  Additionally,  horizontal  channels 
create  shallow  grazing  angles  for  acoustic  waves  which  challenge  the  penetration  of 
thermoclines,  and  broadband  frequency  noise  is  a  much  larger  problem  in  horizontal 
channels  than  in  vertical  channels. 

Through-water  communications  using  alternative  forms  of  energy  have  been 
demonstrated,  usually  with  modulated  coherent  light  systems  (LASER)  and  have  shown 
exceptionally  high  data  rates  are  possible  [Dunbar  91].  Unfortunately,  the  narrow 
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beam- width  of  coherent  light  transmission  systems  requires  tracking  systems  for  both 
receiver  and  transmitter  to  stay  aligned  if  one  or  both  are  maneuvering.  Rapid  absorption 
of  light  in  seawater  limits  the  range  of  transmission  to  short  distances  roughly 
corresponding  to  underwater  visual  range.  Very  Low  Frequency  (VLF)  electromagnetic 
(RF)  transmissions  have  also  been  successfully  utilized  to  communicate  with  submerged 
units,  but  the  bandwidth  and  data  rates  possible  using  VLF  equipment  is  far  too  low  to 
consider  for  any  practical  data  communications  other  than  alertment  systems. 

D.  RELATED  WORK  AND  STATE  OF  THE  ART 

A  good  overview  and  survey  of  acoustic  communication  techniques  is  [Baggeroer  84] 
complemented  by  a  underwater  acoustics  text  such  as  [Urick  83].  Much  of  the  documented 
work  in  acoustic  communications  has  focused  on  physical  layer  signaling  to  achieve 
maximum  bit  rate  with  minimum  error  rate  (raw  bandwidth)  rather  than  reliable  throughput 
(effective  bandwidth).  Encoding  of  data  in  the  acoustic  signal  has  been  well  documented  in 
the  literature.  Ever  in  pursuit  of  the  lowest  bit  error  rates  (BER),  numerous  articles  describe 
modulation  techniques,  all  of  which  operate  exclusively  in  the  physical  layer. 
Unfortunately,  that  is  where  most  of  the  research  stops.  Granted,  the  many  simultaneous 
theoretical  and  engineering  difficulties  involved  in  getting  a  single  slow  acoustic 
communication  link  to  work  effectively  have  much  to  do  with  this  lack  of  progress. 
However,  much  of  the  work  surveyed  is  interesting,  especially  those  describing  work  over 
long  ranges.  For  example,  [Catipovic  94]  describes  state-of-the-art  modems  capable  of 
10kbps  over  10  km  and  3  kbps  at  90  km  The  applicability  of  this  work  may  not  be  as 
relevant  to  AUV  communications  as  we  would  hope  for,  due  to  the  high  power  levels 
required,  but  it  does  in  fact  lend  credence  to  the  feasibility  of  long  range,  high  data  rate 
acoustic  communications.  Granted,  the  purpose  of  the  original  work  was  probably  not 
designed  to  be  implemented  in  an  AUV  or  ALAN,  but  if  hardware  advances  continue  as 
the  trend  has  been,  the  complex  algorithms  that  make  these  kind  of  results  possible  will  be 
implemented  in  hardware  and  deployable.  [Curtin  93],  [Catipovic  93],  [McMullen  94], 
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[Johnson  94]  and  [Merriam  93]  all  reference  the  Acoustic  Area  Network  (ALAN) 
“presently  deployed  in  Monterey  Canyon  connecting  ocean  bottom  seismometers  and 
current  meters  to  Internet,  enabling  real-time  access  to  in  situ  instrumentation’  [Curtin  93]. 
This  is  exciting!  We  would  hope  that  other  work  would  pick  up  where  this  research  left  off, 
as  there  are  great  applications  in  mine  warfare,  oceanography,  and  biology  for  such  a 
system.The  ALAN  described  was  unique  in  that  it  operated  in  the  vertical  channel,  putting 
it  into  a  different  class  of  acoustic  environment  than  the  majority  of  systems  which  will 
need  to  be  created  to  communicate  to  AUVs.  It  is  the  author’s  understanding  that  the 
ALAN  system  was  removed  from  service  recently  due  to  rapid  consumption  of  batteries  in 
the  bottom  nodes  which  rendered  the  system  unusable.  On  a  different  note,  [Zielinski  93] 
claims  data  rates  of  6kbps  over  a  distance  of  3.5  km  in  water  depth  of  only  1 5  meters,  using 
a  multipath  model  and  DPSK  transmission  at  lOkHz.  However,  these  ranges  were 
simulated  using  the  Extend  simulation  package.  It  would  be  wonderful  if  in- water  tests 
were  documented  over  these  ranges  and  frequencies.  [Koelher  92]  describes  a  system 
similar  to  the  Monterey  Canyon  ALAN,  although  a  much  simpler  arrangement  of  a 
bottom-mounted  sensor  communicating  with  a  surface  acoustic  node  via  DataSonics  ATM 
840  and  ATM  850  modems.  The  surface  unit  was  connected  to  a  laboratory  on  shore  by 
Very  High  Frequency  (VHF)  packet  radio  as  was  the  Monterey  Canyon  system  which  used 
microwave  ethemet  bridges.  Again,  this  arrangement  utihzed  the  vertical  channel,  but  this 
work  was  reported  in  a  manner  that  is  of  use  to  follow-on  researchers.  An  excellent 
post-deployment  evaluation  is  presented,  pointing  out  difficulties  in  hardware,  software, 
and  acoustic  interference  from  mooring  chains.  This  report  is  notable  for  the  simple  fact 
that  many  of  the  details  involved  with  actual  in-water  tests  are  touched  upon,  again 
stressing  that  simulations  are  fine  for  laboratory  use,  but  often  data  which  is  most  useful  is 
is  that  which  is  gained  through  often-difficult  in-water  tests,  and  even  then,  caution  must 
be  taken  to  determine  if  the  results  can  be  duplicated  elsewhere. 

Some  of  the  reported  literature  comes  from  industry,  where  claims  to  success  are  quite 
frequent.  However,  a  good  deal  of  the  work  reported  by  industry  is  written  for  and  readable 
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by  the  student,  as  opposed  to  a  large  majority  of  the  work  written  by  academics  which  is 
shrouded  in  technicalities  and  couched  in  what  is  obviously  “community  language” 
unfamiliar  to  the  uninitiated.  [Garmer  92]  describes  the  history  behind  the  Adjustable 
Diversity  Acoustic  Telemetry  System  (AD ATS),  and  the  work  following  it  to  create  the 
successor  of  AD  ATS  which  uses  digital  signal  processing  (DSP).  Data  rates  from  19.5  to 
2500  bps  over  4000  yards  (depending  on  data  rate)  are  claimed.  If  duplicable,  these  figures 
lend  great  promise  to  the  ability  to  pass  Internet  Protocol  over  Seawater  (IPOVERS  W). 
Actual  in-water  tests  in  waters  around  San  Diego  confirmed  the  effectiveness  of  the  system. 
It  is  interesting  that  effects  of  range  on  Bit  Error  Rate  (BER)  as  predicted  by  the  models 
used  to  design  the  system  were  not  realized,  introducing  additional  doubt  into  the 
applicability  of  reported  work  based  on  models  and  simulations  alone.  Approaches  to 
dealing  with  the  problems  of  acoustic  communications  come  from  a  variety  of  directions. 
A  brief  synopsis  follows: 

1.  Modulation  Methods 

Many  acoustic  modem  designers  favor  non-coherent  Frequency  Shift  Keying  (FSK) 
and  Multiple  Frequency  Shift  Keying  (MFSK)  [Catipovic  93]  [Coates  94]  [Vukadin  91] 
due  to  the  simplicity  of  encoding  and  decoding  the  data  carried  by  this  form  of  modulation. 
However,  these  non-coherent  methods  do  not  efficiently  utilize  scarce  available  bandwidth, 
because  dispersed  frequencies  are  often  not  fully  utilized.  Coherent  modulation  techniques, 
such  as  differential  phase  shift  keying  (DPSK)  and  quadrature  phase  shift  keying  (QPSK), 
which  use  a  phase  shift  of  180  and  90  degrees  respectively  to  encode  a  1  or  0  compared  to 
the  previous  bit  transmitted  [Stallings  94]  have  been  proposed  for  use  in  AUV 
communications  applications  [Falahati  91,].  Binary  Phase  Shift  Keying  (BPSK  or  PSK2) 
has  proven  especially  useful  in  vertical  data  links.  Modulation  implemented  by  differential 
coding  has  been  shown  to  enable  receivers  to  solve  the  ambiguity  of  the  carrier  phase,  and 
creation  of  transitions  in  the  transmitted  signal  by  scrambling  have  helped  in 
synchronization  at  the  demodulation  stage  [Ayela  94].  Motion  of  senders  and  receivers  in 


21 


the  water  column  as  well  as  changes  in  the  water  itself  cause  severe  phase  fluctuations  in 
signals  being  carried  by  the  water.  For  this  reason,  [Catipovic  90]  cautions  against  the  use 
of  coherent  modulation  in  underwater  acoustic  channels  (UWA)  but  [Stojanovic  94]  reports 
use  of  receiver  which  performs  optimal  phase  synchronization  and  channel  equalization 
implementing  PSK  over  ranges  from  40  to  140  nm  at  data  rates  from  33  to  1000  symbols 
per  second.  Caution  must  be  used  when  interpreting  this  data  in  view  of  the  purpose  of  this 
thesis.  Ability  to  utilize  coherent  modulation  methods  is  of  interest  to  acoustic  device 
designers  and  should  be  considered  when  standards  discussions  take  place.  Additional 
work  centered  around  adaptive  equalization  has  been  reported,  which  is  a  method  of 
dealing  with  ISI  in  high-speed  digital  communications  in  acoustic  channels.  An  advanced 
tutorial  on  adaptive  equalization  is  presented  in  [Proakis  91].  Most  work  utilizing  adaptive 
equalization  is  done  with  the  intent  of  utilizing  coherent  modulation  techniques.  Adaptive 
equalization  implementation  is  reported  in  [Tarbit  94]  and  [Proakis  94].  [Tarbit  94]  uses 
actual  data  which  was  recorded  from  a  channel  0.5  nautical  miles  in  length  and 
post-processed  in  a  PC  based  simulation.  Of  note  is  the  intention  to  combine  the  adaptive 
equalizer  with  a  beamformer  array  to  additionally  reduce  multipath  effects.  [Howe  94] 
describes  exactly  this  method  to  achieve  reported  data  rates  of  10  kBaud  over  a  0.5  nm 
channel,  but  uses  source  signal  levels  of  184  dB.  [Henderson  94]  also  reports  on  work 
centered  upon  adaptive  beamforming,  which  uses  an  adaptive  algorithm  to  maximize  signal 
strength  received  from  a  desired  direction  while  simultaneously  inserting  nulls  in  the 
direction  from  which  interference  is  being  received.  This  interference  is  usually  caused  by 
multipath.  [Labat  94]  reports  use  of  jointly-optimized  adaptive  equaUzation  and 
synchronization  using  QPSK.  Both  vertical  and  horizontal  acoustic  channels  were  used, 
and  a  beUevable  data  rate  of  3  kBaud  over  a  22  meter  horizontal  path  was  achieved  using 
an  adaptive  equalization  algorithm  implemented  in  a  hardware  digital  signal  processing 

(DSP)  chip. 

Although  intuition  tells  otherwise,  the  most  power-hungry  (battery-power)  operations 
performed  by  DSP  modems  is  not  transmission,  it  is  reception.  Reception  of  a  signal  calls 
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the  DSP  circuitry  into  action,  and  the  complex  computations  designed  to  mitigate  the 
effects  of  multipath  draw  substantial  current  as  compared  to  the  circuitry  invoked  in 
transmission  [Chen  94].  Furthermore,  the  receiver  is  usually  powered  for  longer  periods  of 
time  than  is  the  transmitter.  Transmissions  from  submerged  units  are  usually  answers  to  a 
surface  station  call,  or  a  brief  data  transmission,  while  reception  is  performed  any  time 
there  is  an  acoustic  signal  resembling  the  wake-up  signal  for  the  modem.  After  wake-up, 
the  receiver  must  listen  and  process  until  determination  that  the  message  is  not  for  that  unit, 
after  which  it  can  sleep.  This  wake-up,  listen,  process  cycle  is  a  large  power  drain  on 
limited  power  reserves. 

Linear  frequency  modulation  has  also  been  proposed  as  one  of  three  modulation 
methods  in  a  modem  which  allows  the  user  to  set  the  modulation  method  and  baud  rate 
[Ayela  94].  In  this  method.  Is  and  Os  are  coded  by  modulating  CHIRP,  a  spread  spectrum 
method  commonly  used  in  radar  and  sonar  applications.  This  method  is  easy  to  implement 
and  is  robust  with  respect  to  noise.  However,  it  is  limited  to  low-bit  rate  applications  in 
which  reliability  is  the  goal,  not  high  data  rates. 

Most  signalling  techniques  in  use,  especially  in  navigation,  utilize  narrowband  tone 
bursts.  This  type  of  signal  is  often  employed  because  the  circuitry  required  to  transmit  and 
receive  the  signal  is  fairly  simple.  Timing  resolution  of  signals  such  as  this  depend  on 
minimal  pulse  length  at  as  high  a  power  level  as  is  practical.  If  range  prohibits  reception, 
either  more  power  is  needed  or  pulse  length  must  be  increased.  Increasing  pulse  length 
invites  multipath  corruption  and  requires  a  more  narrow  receiver  bandwidth.  Use  of  a 
coded,  spread-spectrum  signal  has  been  proposed  as  an  alternative  to  individual  channels 
for  control  and  communication,  giving  each  underwater  node  full  use  of  the  available 
bandwidth  [Austin  94]  [Fischer  93].  Binary  phase  shift  keying  (BPSK)  and  Barker  codes 
or  frequency  hopping  with  “chips,”  which  are  broken-up  parts  of  a  single  pulse,  each 
comprised  of  a  different  signal  are  utilized  in  spread-spectrum  applications.  Addressing  or 
node  signal  identification  is  accomplished  by  non-interfering  coded  signals  which  have 
good  auto-correlation  and  poor  cross-correlation  properties.  Direct-sequence 
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spread- spectrum  modulation  is  a  technique  that  spreads  a  conventional  narrowband  signal 
by  mixing  it  with  a  random  bit  stream.  The  result  is  a  dilution  of  the  signal  energy  with 
respect  to  bandwidth.  The  spread- spectram  signal  has  the  same  energy  per  bit  as  the 
narrowband  signal,  but  the  power  density  at  any  one  frequency  is  significantly  lower.  The 
signal  can  be  spread  to  such  a  point  that  it  is  entirely  below  the  noise  level  of  a  conventional 
receiver,  making  it  difficult  to  detect  or  intercept.  The  receiver  of  a  spread-spectmm  signal 
already  knows  and  uses  the  same  encoded  random  bit  stream  to  de-spread  the  signal. 
Through  the  de-spreading  of  the  signal,  the  original  signals  are  restored.  This  process  is 

resistant  to  interference  and  difficult  to  jam. 

Quadrature  Amplitude  Modulation  (QAM)  and  Independent  Single  Sideband 
Modulation  (ISSM)  were  utilized  in  the  U.S  Navy’s  Advanced  Unmanned  Search  System 
(AUSS),  a  very  successful  underwater  search  vehicle  built  using  1970’s  acoustic 
technology  [Walton  92]. 

It  is  important  to  note  that  the  exact  modulation  method  is  not  as  important  as  having 
the  same  modulation  method  on  each  end  of  the  communications  channel.  More  important 
questions  arise  when  considering  reliable  delivery  of  information.  Reliable  error  recovery 
becomes  the  paramount  bandwidth  bottleneck.  Additionally,  coherent  signal 
synchronization  is  essential  to  precisely  determine  the  start  of  a  message  so  that  subsequent 
bits  are  properly  detected,  particularly  in  acoustic  communications  [Stojanovic  94]. 
Ordinarily  coding  techniques  are  used  exclusively  to  improve  digital  signal  processing 
performance,  although  [Vukadin  91]  describes  incorporation  of  Hamming  codes  for 
forward  error  correction  (FEC)  and  [McCue  92]  proposes  the  addition  of  FEC  for  reliability 
in  protocol  implementation.  The  whole  subject  of  forward  error  correction  is  addressed  in 
Chapter  IV. 

2.  Diversity  Processing 

Multipath  travel  often  causes  incoherence  among  transmitted  waveforms.  One  way  of 
recovering  the  data  contained  therein  is  to  receive  the  signal  at  more  than  one  physical 
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location,  where  each  receiver  is  separated  by  a  distance  determined  by  the  frequency  and 
pulse  shape  [Catipovic  91].  This  is  called  spatial  diversity.  There  are  other  forms  of 
diversity  besides  this.  Mitigation  of  multipath  effects  is  one  of  the  largest  problems  in 
acoustic  communications.  Several  approaches  to  dealing  with  it  have  been  described, 
including  temporal,  spatial,  and  frequency  diversity.  Blind  equalization  algorithms 
successfully  recover  phase  in  multipath  rich  “very  shallow”  and  “extremely  shallow” 
channels.  High  data  rates  are  achieved  with  high  level  multi-level  modulation  schemes  such 
as  MPSK.  Modulation  complexity  is  bounded  by  Intersymbol  Interference  (ISI)  and 
reduction  of  noise  margins  [Bessios].  Frequency  diversity  using  MFSK  is  often 
implemented  in  lower-cost  acoustic  modems,  such  as  are  described  in  Table  II-2 

Spatial  diversity  equalization  [Wen  94]  reports  progress  in  using  multiple  receivers  to 
minimize  the  effects  of  multipath  by  combining  the  received  signals,  but  all  the  research 
was  done  using  models  and  a  simulated  ocean  200  meters  deep  and  8  miles  long. 

Another  method  to  increase  reliability  is  beamforming  and  adaptive  equalization. 
Adaptive  equalization  and  beamforming  [Billon  94]  take  into  account  the  transmitter, 
receiver  and  water  depths,  transmission  range,  surface  and  bottom  reflectivity  coefficients, 
frequency  range,  modulation  type  (MPSK  and  MQAM),  transmit  power,  and  sizes  of 
transmit  and  receive  transducer  arrays  to  produce  generalized  signal-to-noise  ratio  and 
related  error  data  rate  of  the  digital  transmission. 

Equalization  methods  based  on  maximum  likelihood  estimation  (MLE)  [Feder  91] 
require  a  priori  knowledge  of  the  channel  characteristics  which  are  often  not  available. 
This  process  is  also  computationally  intensive,  which  explains  the  numerous  complexity 
reduction  articles  [Stojanovic  93] 

3.  Protocols 

Some  research  into  protocols  between  network  nodes  has  been  documented,  and  is 
centered  at  the  medium  access  layer  (MAC).  [McCue]  presents  an  excellent  overview  of 
the  problems  in  medium  access  for  acoustic  devices.  The  send  and  wait  and  sliding  window 
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protocols  are  discussed,  and  trade-offs  between  large  packets  and  retransmit  times  are 
presented.  Forward  error  correction  (P^C)  is  also  presented  as  a  remedy  for  the  problem  of 
excessive  retransmissions  and  will  be  discussed  in  Chapter  IV.  Languages  for 
communicating  between  AUVs  which  utilize  varying  ASCII  message  formats  are 
described  in  [Turner  94],  and  simulation  results  are  presented.  Of  note  is  the  use  of  ASCII 
in  the  language  representation  rather  than  machine  code  primitives,  in  order  to  view 
interactions  between  communicating  units  on  a  regular  video  monitor.  Implications  of  this 
will  be  discussed  later  in  Chapter  IV  in  discussion  of  error  correction  coding.  An  analysis 
of  current  packet  radio  network  (PRN)  protocols  forms  the  basis  for  the  protocol  ideas 
presented  in  [Talavage  94],  but  no  details  as  to  implementation  are  mentioned.  It  is 
assumed  that  results  presented  were  gained  in  simulations.  The  need  for  adaptive  routing 
in  acoustic  node  communication  protocols  is  presented  in  [Johnson  94],  but  this  report 
mainly  discusses  a  new  modem  design,  described  in  [Herold  94]  which  is  essentially  an 
underwater  computer  using  network  routing  protocols  resident  in  a  surface  host.  The 
bandwidth  of  current  acoustic  devises  is  usually  much  less  than  desired  for  underwater 
applications,  so  specialized  languages  are  sometimes  used  for  enhancing  reliable 
communications  in  the  presence  of  high  noise  and  low  bandwidth  [Chappell  94]  [Brutzman 
94]  [Flagg  94]. 

4.  Noise  Negation  Techniques 

One  source  of  noise  which  an  acoustic  communication  system  such  as  one  aboard  an 
AUV  must  deal  with  it  that  which  is  emitted  from  the  AUV’s  own  motors,  screws,  and 
on-board  active  sonars.  Fortunately,  many  noises  emitted  from  an  AUV  can  be  classified 
and  reference  signals  created  which  characterize  the  self-noise.  Cancellation  of  this  noise 
is  possible  using  the  reference  signals  generated  previously.  Two  methods  have  been 
proposed:  the  cascade  method  and  the  multi-channel  adaptive  receiver  algorithm. 
[Catipovic  94]  describes  this  process  and  provides  justification  for  favoring  the 
multichannel  adaptive  receiver  approach.  Another  method  was  applied  in  dealing  with 
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external  noise  in  the  AUSS,  mentioned  earlier.  The  AUSS  was  capable  of  working  at 
depths  of  20,000  feet  and  sending  compressed  video  data  back  to  its  support  vessel  in 
near-real-time.  The  AUSS  was  built  using  1970’s  acoustic  technology,  prior  to  the  advent 
of  digital  signal  processing.  One  aspect  of  the  AUSS  system  which  distinguishes  it  from 
actual  acoustic  networks  is  the  orientation  of  the  signals  passed  between  transmitters  and 
receivers,  as  the  AUSS  utilized  the  vertical  channel  almost  exclusively. 

One  of  the  problems  which  plagued  the  AUSS  vehicle  was  false  carrier  detection,  also 
known  as  double  pings,  in  which  the  attenuated  but  reverberated  uplink  transmissions  from 
the  AUSS  modem  were  mistaken  for  downlink  transmissions  from  the  support  vessel. 


Research 

Group 

Data  Rate 

Modulation 

Method 

and 

Frequency 

Basis 

Error 

Detection/ 

Correction 

Reference 

Acoustic 
Telemetry 
Group,  WHOI 

50(X)bps 

QPSK 

15  kHz 

14Mhz 
PC/XT,  DOS 
OS.RS-232, 

TI 

TMS320C40 

DSP 

None 

[Herold94] 

ORCA 

Instrumentation 

20  bps 
(CHIRP) 

200  bps  (FH) 
2400  bps 
(PSK) 

CHIRP 

Frequency 

Hop(FH) 

(Spread 

Spectrum) 

BPSK 

10-14  kHz 
50-58  kHz 

Motorola 
HC6811, 
56002  DSP. 
RS-232 

Viterbi 

[  Ayela  94] 

Applied 
Remote 
Technology 
(ART) 
ADATS  II 

FSK 

19.5-1250  bps 

3040.5  kHz 

ART  DSP  & 
FFT  cards 
RS-232 

Unknown,  if 
any 

[Garmer  92] 

DataSonics 

2400  bps 

16  tone  MFSK 
13-22  kHz 

Motorola 

68HC11 

AT&T 

DSP-32C 

Unknown, 
perhaps  built 
in  now 

[Chappel  94] 
rMerriam? 

Table  II-2:  Acoustic  modem  sources  and  pertinent  specifications. 
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Research 

Group 

Data  Rate 

Modulation 

Method 

and 

Frequency 

Basis 

Error 

Detection/ 

Correction 

Reference 

Charles 
Starke  Draper 
Laboratory 

1200-4800  bps 

BFSK 
2940.9  kHz 

Intel  386  w/ 
i387NPU, 
INMOS 
transputers, 
TMS320C30 
DSP 

Convolutional 

Coding 

[Fiorillo  90] 

MCRILOR, 

Inc. 

600  Baud 

Direct 

Sequence 

Spread 

Spectrum 

30  or  100  kHz 

Serial 

Correlation  & 
Matched 
Filtering  DSP 
RS-232 

Unknown 

[Fischer  93] 

Table  11-2:  Acoustic  modem  sources  and  pertinent  specifications. 

The  solution  to  this  problem  was  to  cause  the  submerged  search  vessel  to  periodically 
sleep  and  go  into  receive  mode  to  listen  for  downlink  transmissions.  The  presence  of  a 
carrier  during  sleep  time  meant  a  down  transmission  was  in  progress.  Additionally,  the 
acoustic  link  was  segregated  into  two  separate  frequencies  to  avoid  feedback  of  the 
transmitted  signal  into  either  the  support  ship  or  the  search  vessel  [Walton  92]. 

Errors  in  imaging  data  also  caused  problems  with  the  AUSS.  Even  with  reliable  2400 
bps  communications  between  the  AUSS  and  the  surface  vessel  achieving  a  bit  error  rate 
(BER)  of  less  than  3.8x10-6,  a  one-bit  transmission  error  resulted  in  the  corruption  of  16 
pixels  of  compressed  sensor  image.  The  solution  was  to  implement  a  technique  which 
threw  out  and  retransferred  a  section  of  compressed  data  if  a  check  sum  error  was  found. 
This  technique  is  described  by  [Watson  91]  and  [Uhrich  92]. 

5.  Related  Non-Acoustic  Research 

In  many  ways  underwater  applications  have  parallels  with  space  applications, 
including  the  same  conununication  problems.  Although  electromagnetic  radiation  in  the 
form  of  radio  frequency  energy  passes  easily  through  the  earth’s  atmosphere  and  on  into 
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deep  space,  it  still  is  affected  by  interference,  propagation  delays,  and  attenuation.  Several 
projects  involving  deep  space  have  been  documented  including  [Jabbari  84]. 

E.  COMMUNICATION  HARDWARE:  MODEMS 

Sound  energy  is  a  physical  disturbance  of  the  envirorunent  while  computers 
communicate  using  electrical  voltages  which  are  understood  as  digital  data.  Modems  are 
used  to  convert  the  electrical  pulses  generated  by  the  computer  into  acoustic  energy  which 
is  then  transmitted  and  received  via  transducers. 

Modem  development  for  underwater  applications  has  only  experienced  extensive 
academic  and  commercial  attention.  Beginning  with  the  original  “Gertrude”  underwater 
telephone  for  communicating  between  naval  ships  and  submarines,  the  technology  had 
essentially  stagnated  at  the  analog  single-sideband  modulation  level  until  digital 
microprocessor  technology  became  available  in  the  ‘70s  and  ‘80s.  Recently,  low-cost  DSP 
technology  and  parallel  advances  in  radio  and  telephone  communications  enabled  the 
constmction  of  highly  sophisticated  acoustic  modems  which  are  relatively  dependable  and 
consumed  small  amounts  of  power  [Catipovic  93].  Many  modems  utilized  in  underwater 
network  research  operated  at  a  maximum  of  4800  baud,  with  most  using  rates  around  2400 
baud.  Typical  data  compression  was  described  for  a  commercial  search  system  as  a  two- 
dimensional  discrete  (DCT)  cosine  transform  upon  whose  results  Huffman  and  run-length 
coding  were  performed  using  DSP  on  the  host  computer  [SEACO  92].  Nevertheless 
propagation  delays  and  multiplex  prevented  any  higher  data  rates.  Recent  advances  in  DSP 
applications  to  acoustic  modem  technology  has  made  higher-rate  acoustic  modems 
feasible.  DataSonics,  located  in  Cataumet,  Massachusetts  produces  a  family  of  acoustic 
modems,  such  as  the  one  shown  in  Figure  II -6  More  information  about  these  modems  can 
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be  found  in  [Datasonics  94]  and  [Datasonics  undated].  Orca  Instramentation  of  Brest, 


Figure  II-6:  Datasonics  ATM-860  acoustic  modem  [DataSonics  94]. 

France  is  also  a  well-known  producer  of  acoustic  modems.  DiveTracker,  a  multi-purpose 
digital  conununications  and  navigation  system  for  divers,  ROVs  and  AUVs  combines  a 
modem  with  a  HC681 1  microprocessor  to  provide  long  baseline  (LBL)  and  short-baseline 
(SBL)  navigation  to  both  diver  and  surface  station,  as  well  as  depth  and  tank  pressure 
telemetry  data  to  surface  supervisors  [Ragg  94].  Message  communication  is  also  provided 
by  several  different  protocols  with  an  RS-232  interface. 

Desert  Star  Systems  of  Moss  Landing,  California  produces  the  DiveTracker  system. 
The  system  uses  MFSK  for  through-water  communication  and  navigation.  The  sonar 
modem  operates  in  the  40-75  kHz  range,  and  utilizes  frequency-hopping  techniques  to 
exploit  multipath  propagation  in  shallow-water  environments.  Navigation  is  provided  by 
acoustic  ranging  with  other  DiveTracker  units.  Omnidirectional  communications  are 
transmitted  at  rates  from  50  to  300  bps  over  ranges  of  300  to  3000  feet,  depending  on 
environmental  conditions.  The  diver’s  unit  is  designed  for  depths  of  up  to  1000  feet  of 
seawater  (fsw),  and  is  capable  of  communicating  with  a  surface  unit  and  up  to  9  other 
DiveTrackers,  forming  an  underwater  network.  The  surface  unit  is  not  submersible,  but 
uses  an  attached  submersible  transducer  and  has  the  same  circuitry  as  the  diver’s  station. 
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All  software  for  the  DiveTracker  system  is  written  in  C,  making  the  unit  software 
programmable  by  the  user.  Various  software  programs  can  be  loaded  into  the 
DiveTracker’s  flash  memory  and  executed  fi'om  either  the  front  panel,  in  the  case  of  the 
Diver’s  Station  (DTl-D-S),  or  from  an  attached  PC,  in  the  case  of  the  Surface  Station  or 
Remote  Unit  (DTl-DRY  or  DTl-R-S).These  software  programs  are  written  by  Desert  Star 
Systems  and  compiled  using  a  Archimedes  MS-DOS/  MC68HC1 1  cross-compiler.  The 
compiled  code  is  then  loaded  into  one  or  more  pages  of  flash  memory  using  an  accessory 
program  named  DiveTerm.  The  main  program  the  DiveTracker  is  designed  to  run  is  a 
navigation  and  communication  program  named  SmartDive.  The  divers’s  unit  is  shown  in 
Figure  11-7.  Connector  plugs  are  for  sonar,  RS-232  communications,  battery  charging,  and 
high  pressure  (HP)  air  sensor.  Dimensions  are  8.5  x  3.5  x  2. 16  inches.  A  surface  station  unit 
is  shown  in  Figure  II-8.  Connector  plugs  are  for  2  sonar  transducers,  RS-232 
communications,  and  1 2  volt  direct  ciurent  (DC)  power.  Dimensions  are  5  x  7  x  1 .5  inches. 
A  transducet  used  by  all  the  DiveTracker  units  is  displayed  in  Figure  11-9.  Not  shown  is  a 
remote  station,  which  is  built  identically  to  the  divers’  station  but  lacks  a  display  screen  and 
a  keypad  for  data  entry. 
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Figure  11-8:  DivelVacker  surface  station  DTl-DRY  [Desert  Star 
Systems  95]. 
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Figure  II-9:  DiveTracker  transducer  [Desert  Star  Systems  95]. 

F.  SUPPORTING  EQUIPMENT:  MICROWAVE  RADIO  ETHERNET 

Several  methods  are  employed  to  transfer  data  in  real-time  from  submerged  modems 
to  users  on  land,  including  VHP  packet  radio,  microwave  ethemet  bridges,  and  fiber-optic 
cable.  VHP  packet  radio  has  been  successfully  used  although  data  rates  and  bandwidth  are 
not  as  high  as  are  available  with  microwave.  Experimental  results  are  described  for 
sea-to-shore  communications  using  an  acoustic  modem  between  a  bottom  station  and  a 
moored  buoy  with  data  being  relayed  from  the  buoy  via  VHP  packet  radio  to  a  shore 
station,  then  via  dial-up  modem  link  between  the  shore  station  and  the  remote  laboratory 
[Koehler  92]. 

Microwave  is  the  most  logical  connection  to  buoy  links  and  offshore  acoustic  LANs 
as  it  provides  maximum  bandwidth  at  minimal  power.  However,  range  is  limited,  often  to 
less-than-visible  ranges.  Experience  with  two  different  microwave  ethemet  bridges  is 
documented  in  Appendix  D. 
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G.  OPERATIONAL  APPLICATIONS 


1.  Voice 

Transmission  and  reception  of  voice  was  realized  in  the  UQC-1  underwater  telephone 
which  was  built  for  the  US  Navy  to  enable  communications  between  surface  ships  and 
submarines  or  just  between  submarines.  Nicknamed  “Gertrude,”  the  equipment  uses 
single-sideband  voice  modulation  of  a  8  kHz  carrier.  This  was  a  completely  analog  system. 
Newer  communications  systems  are  leaning  toward  all-digital  signaling,  incorporating 
many  of  the  acoustic  channel  optimization  methods  outlined  above.  Of  note  is  the  work 
reported  in  [Goalie  94]  which  describes  progress  towards  a  digital  acoustic  phone  capable 
of  actual  voice  transnrussions  in  real-time.  An  example  of  an  operational  commercially 
available  voice  communication  device  is  shown  in  Figure  11-10. 


Figure  ILIO:  OTS  Single  Sideband  Acoustic  Comm  System  [OTS 
Corporation]. 
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2.  Autonomous  Underwater  Vehicles 

Without  a  doubt,  the  need  for  reliable  acoustic  communications  at  the  IP  level  is  due 
to  the  advancements  being  made  in  autonomous  underwater  vehicle  technology.  As 
demands  for  deep-diving,  all-weather  capable  vehicles  increase,  more  requirements  are 
placed  on  communication  systems  to  effectively  transfer  mission  parameters,  navigation 
information,  and  system  status  to  operators  and  other  vehicles  such  as  remote  operated 
vehicles  (ROVs).  In  addition,  the  trend  towards  AUV  utilization  in  every  aspect  of  mine 
warfare  continues  to  put  a  press  on  development  of  reliable,  high  level  systems.  For 
example,  the  Naval  Postgraduate  School  Phoenix  is  currently  undergoing  tests  with  a 
Desert  Star  Systems  DiveTracker  conununication  and  navigation  system,  described  earlier. 
The  focus  of  this  vehicle  is  autonomous  minefield  search  and  localization  of  mine-like 
objects.  After  the  vehicle  retimis  from  a  search  mission,  the  data  collected  by  the  AUV  wUl 
be  analyzed.  If  a  minelike  object  is  found,  the  vehicle  will  be  commanded  to  re-aquire  the 
target  and  place  an  explosive  charge  nearby  which  will  be  detonated  at  a  later  time. 
Commands  and  status  messages  will  be  passed  to  and  from  the  vehicle  acoustically  while 
it  is  submerged  and  via  microwave  Ethernet  link  9see  Appendix  D)  while  surfaced. 

H.  SUMMARY 

Computers  communicate  via  networks  and  utilize  specific  protocols  to  transfer 
information  from  computer  to  computer  and  from  layer  to  layer  in  a  stack.  Physical  layer 
devices  are  responsible  for  encoding  the  data  in  order  to  maximize  efficiency  of  the 
medium  and  available  bandwidth.  Acoustic  modems  are  available  with  many  different 
modes  of  transmission  and  reception,  but  reliability  is  still  a  large  problem.  Digital  signal 
processing  is  enabling  advancements  in  range  and  data  rates  of  underwater  devices,  but 
there  is  much  work  yet  to  be  done  in  this  area.  Noteable  sources  and  current  work  was 
reviewed,  and  there  exists  a  large  amount  of  documentation  that  is  not  only  written  at  a  very 
high  language  for  the  neophyte,  but  much  of  the  work  is  reported  on  by  numerous  people 
without  anyone  duplicating  the  work  for  verification  purposes.  The  focus  of  underwater 
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data  transmission  is  most  strongly  directed  at  control  of  AUVs,  but  acoustic  networks  and 
commercial  applications  such  as  diver  support  and  oceanography  data  collection  also 
require  reliable,  long-lasting  efficient  units  to  communicate. 
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III.  PROBLEM  STATEMENT 


A.  INTRODUCTION 

This  section  addresses  specific  problems  in  underwater  acoustic  communications 
which  have  not  been  a  point  of  focus  in  the  reported  literature,  yet  will  greatly  limit  the 
effectiveness  and  reliability  of  underwater  devices.  These  problems  center  around  the  fact 
that  most  underwater  devices  have  limited  power  supplies,  since  most  are  battery  operated, 
and  thus,  communications  protocols  must  be  designed  with  this  limitation  in  mind. 
Methods  of  protecting  against  the  problem  of  battery  depletion  due  to  excessive 
retransmissions  are  available  and  is  addressed.  Further,  a  large  majority  of  the  reported 
work  has  focused  on  point-to-point  communications,  from  one  acoustic  device  to  another, 
not  on  networked  communication  in  a  broadcast  environment.  One  reason  for  this  is  lack 
of  compatibility  among  acoustic  devices.  Another  is  the  difficulty  in  specifying  a  protocol 
that  will  work  with  the  harsh  conditions  and  extreme  propagation  delays  for  which  acoustic 
environments  are  well  known. 

B.  DATA  COMMUNICATION  IN  AN  UNFRIENDLY  WORLD 

In  an  underwater  environment,  an  autonomous  entity  will  often  have  difficulty  passing 
a  message  reliably  to  its  intended  receiver.  Common  protocols  utilized  in  terrestrial 
networks  depend  on  an  acknowledgment/resend  mechanism:  data  not  received  is  not 
acknowledged,  causing  the  sender  to  resend  the  data  after  a  preset  time  period,  or  the 
message  is  received  in  error,  causing  the  receiver  to  send  a  Not  Acknowledged  (NAK)  to 
the  sender,  who  in  turn  resends  the  required  data.  The  problem  with  this  common  approach 
is  that  an  underwater  channel  may  have  so  much  interference,  noise,  or  attenuation  that  the 
message  is  not  received  in  its  entirety  without  error.  Under  this  protocol,  the  sender  will 
continue  to  send  and  resend,  until  its  power  resources  have  been  depleted.  Unfortunately, 
autonomous  underwater  entities  are  exclusively  dependent  on  batteries,  and  transmission 
requires  substantial  power  which  is  in  limited  supply.  Ultimately,  the  sender  might  attempt 
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to  resend  the  message  until  it  has  depleted  its  power  supply,  and  then  it  ‘"dies.”  This  is  called 
the  ‘‘retry  until  you  die”  syndrome.  What  is  needed  is  a  way  to  allow  the  receiver  to  correct 
the  messages  received  in  error  in  order  to  reduce  or  eliminate  the  need  for  retransmission. 

C.  TWO  MODEMS  DO  NOT  A  NETWORK  MAKE 

Currently  there  are  many  different  acoustic  modems  used  by  commercial  firms  and 
research  groups,  as  shown  in  Table  II-2.  Typically  devices  built  by  different  teams  are 
completely  incompatible,  both  on  the  wet  side  (in- water  acoustics)  and  dry  side  (upstream 
computer  interface).  Acoustic  incompatibilities  are  understandable  given  the  difficulty  of 
adequate  underwater  communications  among  diverse  acoustic  environments.  Nevertheless 
the  many  dissimilar  upstream  interfaces  are  often  made  to  similar  computers  for  similar 
reasons.  Apart  from  the  standard  RS-232C  interface  (discussed  in  Chapter  11),  little  thought 
has  gone  into  design  for  compatibility.  It  seems  obvious  that  the  goal  of  underwater 
communications  design  personnel  ought  to  be  connectivity  with  the  global  Internet.  In  so 
doing,  any  user  might  then  be  able  to  access  information  contained  on  an  underwater  entity 
in  near-real-time  while  at  a  physical  location  far  removed  from  the  ocean  itself,  using 
existing  Internet  protocols.  These  are  the  same  protocols  which  allow  applications  such  as 
mail,  FTP,  and  telnet  to  be  run  on  any  computer  which  is  connected  to  the  Internet.  Internet 
connectivity  means  that  a  scientist  or  student,  (assuming  they  have  the  proper  authority), 
might  initiate  or  modify  a  mission  profile  of  the  NPS  AUV  while  conducting  a  mission  in 
Monterey  Bay,  merely  by  sending  electronic  mail  to  the  AUV.  Standardized 
communications  mechanisms  already  exist  for  one-to-one  and  several-to-many  delivery  of 
imagery,  audio,  video  and  positional  information.  Adding  Internet  Protocol  (IP) 
compatibility  and  reliability  to  current  acoustic  communications  protocols  can  provide  all 
of  these  capabilities  and  extend  the  Internet  underwater.  From  a  networking  perspective, 
current  acoustic  communications  devices  only  provide  low-level  functionality  at  the 
physical  layer  and  the  data  link  layer.  The  key  to  making  Internet  connectivity  a  reality  is 
to  analyze  the  functions  of  the  current  Internet  protocols,  and  extract  from  them  the  tasks 
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that  must  be  accomplished  at  each  layer.  These  tasks  must  then  be  applied  to  a  protocol 
which  is  created  specifically  for  an  underwater  environment  which  uses  acoustic 
communications.  The  addition  of  higher  layer  protocols  for  reliable  transport  and 
applications  connectivity  can  augment  existing  acoustic  communications  devices  in  order 
to  be  compatible  with  the  IP  suite. 

Users  merely  wish  to  send  and  receive  messages  via  computer  interfaces.  The  precise 
split  between  the  functionality  embedded  in  the  acoustic  device  and  the  functionality 
performed  by  the  host  computer  varies  greatly  among  documented  applications  and 
available  devices.  Given  that  the  commonality  shared  by  various  devices  is  much  greater 
than  the  differences,  there  exists  tremendous  potential  for  improved  interoperability  among 
acoustic  telemetry  systems. 

The  methods  used  to  logically  partition  the  functionality  of  encoding  and  decoding  for 
data  and  signal  processing  can  also  vary  widely.  Many  inefficiencies  and  incompatibilities 
are  introduced  if  network  considerations  are  ignored.  When  multiple  layers  are  intended  to 
work  together,  a  networked  approach  provides  a  set  of  protocol  layers  which  logically  and 
efficiently  splits  functionality  requirements  into  a  consistent  hierarchy.  This  provides 
interoperability,  efficiency  and  appropriate  degrees  of  abstraction  and  simplification. 

An  example  is  in  order  here.  Ethernet  is  a  common  LAN  technology.  Different 
computers  with  different  hardware  interfaces  can  each  communicate  over  the  medium  of  a 
shared  cable.  Although  many  signaling  schemes  are  possible  on  the  shared  wire,  a  single 
standardized  protocol  defines  the  hardware  signaling  to  be  performed  by  various  network 
interface  cards  (NIC) .  Similarly,  at  higher  levels  of  abstraction  in  the  computer,  an 
application  program  cares  little  if  the  underlying  physical  medium  utilizes  Ethernet,  Fiber 
Distributed  Data  Interface  (FDDI)  or  even  Serial  Line  Internet  Protocol  (SLIP). 
Communication  packets  are  still  sent  down  to  the  hardware  interface,  and  in  each  case 
network  protocols  ensure  compatibility  despite  different  hardware  and  software.  Thus 
inconsistencies  between  key  sonar  parameters  such  as  frequency,  signalling  and  low-level 
coding  need  only  exist  at  the  physical  and  data  link  layers  of  a  network  hierarchy. 
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Transducer  and  signalling  hardware  components  might  be  replaced  without  requiring  any 
changes  to  the  interface  software  above  the  physical  layer  if,  for  example,  a  new  modem 
becomes  available  or  a  different  encoding  scheme  is  implemented  in  the  modem. 

The  timing  delays  and  ambiguities  introduced  by  the  slow  propagation  rate  of  sound 
in  water  play  a  dominant  role  in  the  selection  of  a  communication  protocol.  Timing 
characteristics  of  the  channel  determines  more  what  protocols  cannot  be  used  than  which 
ones  should.  Synchronization  between  transmitter  and  receiver  is  key  to  making  many 
coherent  modulation  transmission  schemes  work.  Commonly  accepted  terrestrial  network 
access  protocols  and  physical  level  protocols  simply  do  not  work  due  to  the  propagation 
delay  and  unreliability  of  the  acoustic  channel.  At  the  forefront  of  the  acoustics  problem  is 
the  lack  of  precise  data  for  local  environments,  in  addition  to  the  non-stationary  condition 
states  which  characterize  them. 

D.  A  POSSIBLE  SOLUTION 

Defining  mission-oriented  languages  for  acoustic  communications  with  AUVs  are 
useful  as  a  way  to  improve  clarity,  improve  robustness,  and  reduce  bandwidth  requirements 
through  concise  syntax.  Nevertheless,  such  approaches  do  not  provide  a  generalized 
solution.  An  optimal  communications  methodology  is  data-format  independent,  i.e.  the 
acoustic  channel  can  pass  arbitrary  binary  data.  Such  a  capability  includes  compatibility 
with  8-bit  ASCn  text  which  is  easily  read  by  both  machines  and  humans.  Ordinarily  text  is 
the  most  practical  and  dependable  format  for  acoustic  data  transmission  to  underwater 
electronic  devices  such  as  AUVs  and  remote  sensors.  A  simple  general  and  sufficient 
telemetry  scheme  is  to  start  each  message  with  a  reserved  keyword,  followed  by  zero  or 
more  corresponding  parameters  [Bmtzman  94].  Numerous  efficient  compression  and 
encryption  schemes  exist  which  can  further  reduce  the  size  of  any  message  to  an 
information-theoretic  minimum  within  acceptable  computational  overhead  costs 

[Brutzman  92]. 
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E.  SUMMARY 


It  is  proposed  in  this  thesis  that  the  way  to  solve  the  “retry  until  you  die”  problem  is  to 
reduce  retransmissions  of  messages  by  forward  error  correction,  a  method  of  data  encoding 
which  gives  the  receiver  the  ability  to  correct  data  received  in  error  up  to  a  preset  bound. 
In  addition,  it  is  proposed  that  by  analyzing  the  existing  Internet  Protocol  stack  and 
determining  what  functions  each  layer  performs  in  a  terrestrial  network,  layer  functions  for 
an  underwater  acoustic  network  could  be  identified.  Once  layer  functions  are  mapped  out, 
the  path  is  clear  for  standards  organizations  to  begin  building  an  acoustic  network  standard 
based  on  the  Internet  Protocol. 
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IV.  DATA  ENCODING  FOR  RELIABILITY 


a’  introduction 

Forward  error  correction  has  been  proposed  as  a  way  to  increase  reliability  of 
underwater  acoustic  devices.  In  this  section,  various  methods  of  error  detection  and 
correction  will  be  discussed.  An  in-depth  look  at  Hamming  error  detection  and  correction 
codes  is  presented.  Following  that,  differences  between  block  and  non-block  codes  are 
defined.  Reasons  for  implementation  of  ASCII-based  communications  systems  are  given. 
Finally,  data  encryption  for  security  and  data  compression,  which  are  two  related  subjects 
are  briefly  mentioned  in  view  of  the  fact  that  each  process  is  designed  to  modify  the  data 
in  different  ways  in  order  to  meet  users’  needs,  but  they  can  be  made  to  work  together  with 
forward  error  correction  to  increase  reliability  and  security. 

B.  OVERVIEW 

Communication  systems  connect  data  sources  to  data  users  through  chaiuiels.  A 
telephone  line,  a  microwave  link  and  a  coax  Ethernet  link  are  all  chaimels,  as  is  the  path  of 
acoustic  energy  through  the  water  from  a  sender  to  a  listener.  In  every  channel,  noise 
attenuates  and  corrupts  the  data  carried  by  the  medium.  Errors  in  data  communications  are 
produced  in  one  of  two  ways:  static  events,  whose  behavior  and  existence  are  well  known, 
and  transient  events,  which  occur  randomly.  Transients  are  more  difficult  to  deal  with  since 
they  cannot  be  anticipated.  Most  common  transient  events  are  impulse  noise  or  burst  noise, 
which  can  be  described  as  periods  of  disrupting  noise  bounded  on  either  side  by  periods  of 
no  noise  [Campbell  87].  An  excellent  survey  of  noise  in  the  acoustic  environment  is  [Urick 
83].  One  method  used  to  deal  with  errors  is  retransmission  of  the  message.  Retransmission 
of  the  message  received  in  error  is  utilized  in  systems  where  the  propagation  times  are 
minimal  and  there  is  no  cost  to  retransmit  the  message.  Ethernet  LANs  utilize 
retransmission  extensively  because  the  above  caveats  fit  the  Ethernet  protocol  well.  As 
discussed  in  Chapter  Ill,  transmission  of  an  acoustic  signal  requires  substantial  power 
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which  is  in  limited  supply,  and  lack  of  an  acknowledgment  can  cause  the  sender  to  deplete 
its  batteries. 

There  is  a  way  to  solve  this  problem,  and  it  is  the  method  utilized  by  remote  robots 
which  inhabit  an  equally  unfriendly  environment:  deep  space.  Deep-space  probes  such  as 
Voyager  are  subject  to  the  same  challenges  as  autonomous  underwater  entities:  critical 
dependence  on  limited  power  reserves,  huge  signal  propagation  delays,  and  extremely  low 
signal  power  levels  vulnerable  to  noise  and  attenuation  [Walker  94].  A  data-encoding 
method  known  as  forward  error  correction  (FEC)  can  be  used  to  provide  the  receiver  with 
enough  redundancy  that  the  contents  of  the  message  can  be  reconstructed  even  if  it  is 
received  with  significant  errors,  preventing  a  lengthy  transmission  request  and  subsequent 
power-robbing  retransmission  of  the  message.  Since  this  correction  occurs  on  the  receiver 
side  where  the  message  has  been  forwarded,  it  is  caUed  forward  error  correction.  The 
converse  situation  is  when  errors  can  only  be  eliminated  by  resending  them  message  from 
the  sending  (backward)  side.  Thus  a  (NAK)/retransmission  sequence  constitutes  backward 
error  correction. 

Most  ACK/NAK  schemes  operate  on  simple  error  detection,  the  process  of  checking 
the  incoming  data  for  corruption  and  inverted  bits.  This  is  usually  done  by  a  simple  parity 
checking  scheme,  where  blocks  of  data  are  summed  modulo-2  and  a  parity  bits  for  either 
even  or  odd  parity  is  appended.  In  this  method,  no  correction  is  available.  The  parity  bits 
simply  let  the  receiver  know  there  is  an  error  somewhere  in  the  data.  A  more  advanced 
method  is  cyclic  redundancy  checking  (CRC)  which  works  as  follows:  Given  a  k-bit  frame 
or  message,  the  transmitter  generates  an  n-bit  sequence,  known  as  Si  frame  check  sequence 
(FCS),  so  that  the  resulting  number,  consisting  ofk-^n  bits,  is  exactly  divisible  by  some 
predetermined  number.  The  receiver  then  divides  the  incoming  frame  by  the  same  number 
and,  if  there  is  no  remainder,  assumes  that  there  was  no  error.  This  method  also  only  lets 
the  receiver  know  if  there  were  errors;  it  does  not  let  the  receiver  know  where  the  errors 
were  or  how  to  fix  them. 
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A  better  approach  is  to  not  only  allow  the  receiver  to  detect  errors,  but  also  to  correct 
them,  up  to  a  limit  determined  by  the  algorithm  used  to  encode  the  data.  Algorithms  used 
to  encode  messages  for  this  purpose  are  error-correcting  codes.Thc  key  to  forward  error 
correction  (correction  at  the  receiver)  is  redundancy.  Indeed,  the  simplest  error-correcting 
code  is  simply  to  repeat  everything  several  times.  If,  for  example,  it  is  anticipated  that  there 
will  be  no  more  than  one  error  to  occur  in  transmission  of  every  three  bits,  then  repeating 
each  bit  three  times  and  using  “majority  vote”  at  the  receiving  end  will  guarantee  that  the 
message  is  heard  correctly  (e.g.  Ill,  000, 011,111  will  be  correctly  heard  as  101 1).  In 
general,  n  errors  can  be  compensated  for  by  repeating  things  2n  +  1  times.  However,  this 
is  inefficient,  and  there  are  better  ways  of  adding  redundancy  to  the  data  than  to  repeat 
everything. 

Figure  FV-l  shows  a  block  diagram  of  a  digital  communication  system  that  encodes 
transmitted  data  with  additional  information  prior  to  transmission.  Data  enters  the  system 
from  the  source,  and  is  then  processed  by  a  source  encoder  designed  to  represent  the  source 
data  in  a  more  compact  manner.  An  example  of  this  is  the  serial  output  of  a  PC 
communicating  with  an  AUV  at  sea.  A  suitable  bit  rate  for  synchronous  transmission 
underwater  might  be  4800  bps,  which  means  each  bit  has  a  duration  of  208.5  ms.  Fourier 
analysis  shows  that  a  continuous  stream  of  alternate  1  ’s  and  O’s  requires  a  wider  bandwidth 
than  any  other  combination  of  bits  [Falahati  91].  Since  there  is  a  good  possibility  of  this 
happening,  the  bandwidth  requirements  for  this  case  must  be  satisfied.  If  the  maximum  bit 
rate  is  4800  bps,  the  minimum  bandwidth  required  is  2400  Hz.  The  source  encoder  samples 
2  bits  at  a  time  and  produces  a  four-level  stream  of  data  symbols  {5/}.  Each  level 
corresponds  to  a  different  bit  combination,  such  as  the  integral  symbols  00,  01,  1 1,  or  10. 
Since  each  level  has  a  duration  of  2  symbols  (417  ms),  the  symbol  rate  (2400  Baud)  is  half 
the  bit  rate  and  the  bandwidth  required  is  halved  to  1200  Hz.  The  output  of  the  source 
encoder  is  the  source  codeword.  The  source  codeword  is  then  processed  by  the  channel 
encoder  which  produces  another  sequence  called  the  channel  codeword.  The  channel 
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codeword  is  a  new,  longer  sequence  of  symbols  that  has  the  information  redundancy 
discussed  above  built  into  it. 

The  modulator  then  converts  each  symbol  of  the  channel  codeword  into  a 
corresponding  analog  symbol  from  a  finite  set  of  possible  analog  symbols.  The  analog 
symbol  string  is  then  transmitted  through  the  channel.  Noise  and  other  types  of  interference 
in  the  channel  alters  the  analog  signal  so  that  it  now  looks  different  from  what  the 
modulator  actually  transmitted. 


Digital  Communication  System 


4 


Noise 


Figure  IV-1:  Block  Diagram  of  a  digital  communication  system 
[Blahut  83]. 
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The  demodulator  converts  each  received  channel  output  symbol  to  one  of  the  channel 
codeword  symbols.  However,  each  demodulated  symbol  is  a  estimate  of  the  original 
symbol,  because  the  demodulator  makes  mistakes  due  to  channel  noise.  The  demodulated 
symbol  sequence  is  called  the  received  word.  Due  to  errors  in  the  channel,  the  received 
word  often  does  not  look  exactly  like  the  channel  codeword. 

The  channel  decoder  then  uses  the  redundant  information  in  the  channel  codeword  to 
correct  the  errors  in  the  received  word  and  produce  an  estimate  of  the  source  codeword.  As 
long  as  all  errors  are  corrected,  the  received  codeword  matches  the  original  source 
codeword.  The  source  decoder  performs  the  inverse  operation  of  the  source  encoder  and 
produces  an  output  for  the  user  [Blahut  83].  As  long  as  the  errors  are  within  the  capability 
of  the  error-correcting  code  to  handle,  no  retransmission  is  needed.  Thus  this  system  has 
achieved  the  goal  of  reducing  retransmissions. 

C.  HISTORY  OF  THE  HAMMING  CODE 

While  at  Bell  Laboratories  in  1948,  Claude  Shannon  proved  that  any  communication 
channel  has  a  number  C  (in  units  of  bits  per  second)  associated  with  it  which  is  the  capacity 
of  the  channel  [Blahut  83].  This  number  is  significant  in  that  whenever  the  transmission 
rate  R  (in  bits  per  second)  required  of  the  channel  is  less  than  C,  it  is  possible  to  design  an 
error-control  code  whose  probability  of  output  error  is  as  small  as  is  desired.  Unfortunately, 
Shannon  did  not  specify  exactly  how  to  build  these  error-control  codes.  He  just  proved  that 
they  existed. 

Adding  extra  bits,  called  parity  bits,  to  a  message  provides  the  ability  to  detect  and 
correct  errors.  The  extra  bits  are  the  redundant  information  mentioned  above.  The  goal  of 
adding  parity  bits  is  to  increase  the  number  of  possible  code  words  and  define  a  valid  and 
an  invalid  set  For  example,  a  three-bit  data  word  has  8  possible  combinations  which  are  all 
valid  words.  Changing  one  bit  in  any  of  the  8  words  produces  another  valid  but  erroneous 
word.  Addition  of  a  fourth  bit  now  produces  16  available  combinations,  8  with  an  even 
number  of  Is  and  8  with  an  odd  number  of  Is.  Either  the  even  or  odd  set  may  be  used  as 
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the  8  viable  codewords,  but  in  either  set,  changing  one  bit  removes  that  word  from  the  set 
of  correct  combinations.  However,  changing  2  bits  will  now  produce  another  word  in  the 
set  of  correct  words.  The  number  of  bits  which  must  be  changed  to  produce  another  vahd 
codeword  is  called  the  Hamming  distance,  named  after  Richard  W.  Hamming,  who  at  that 
time  also  worked  for  Bell  Laboratories. 

Parity  bits  added  to  a  two-dimensional  matrix  of  bits,  such  as  are  found  in  a  magnetic 
tape,  became  known  as  Vertical  Redundancy  Check/Longitudinal  Redundancy  Check 
(VRC/LRC).  This  method  of  error  detection/correction  enabled  correction  of  single  bit 
enors  and  detection  of  double  bit  errors,  and  became  known  as  a  “double-detection,  single 
correction”  code.  The  location  of  the  bit  in  error  was  determined  after  reading  the  tape  into 
a  buffer  by  computing  the  parity  across  the  matrix  for  each  row,  then  computing  the  parity 
down  the  matrix  for  each  column.  The  row  in  error  (incorrect  parity)  and  the  column  in 
error  “point”  to  the  bit  in  error.  Assuming  only  one  error  had  occurred,  inversion  of  that 
identified  bit  corrects  the  block  of  data  and  hence  the  message  is  corrected. 

Hamming  error  correcting  codes  arose  from  a  desire  to  take  humans  out  of  the  loop 
when  checking  early  computers  for  errors  [Hamming  86].  Hamming  codes  redundantly 
encode  information  in  an  optimally  efficient  scheme  suitable  for  a  variety  of  error 
probability  distributions,  over  intervals  and  frequencies  specified  by  the  code  designer. 
Error  detection  and  correction  can  be  achieved  at  any  degree  of  reliability  desired,  at  a 
logarithmically  increasing  bandwidth  cost  of  additional  parity  bits  and  a  linearly  increasing 
computational  cost  of  decoding.  The  codes  were  designed  in  the  years  following  Shannon  s 
work,  and  were  able  to  detect  and  correct  errors  by  producing  a  syndrome,  i.e.  the  “address” 
of  the  bit  in  error.  Hamming  codes  add  parity  bits  to  a  message  in  a  specific  pattern,  such 
that  the  parity  bits  have  specific  bit  positions  reserved  for  them.  Each  parity  bits  “covers” 
a  domain  of  bit  positions.  For  example.  Figure  rV-2  shows  a  Venn  diagram  which 
graphically  represents  this  idea  for  a  seven-bit  word  which  has  four  data  bits  and  three 
parity  bits.Each  of  the  3  parity  bits  is  computed  from  the  values  of  the  bits  in  the  positions 
which  that  parity  bit  “covers.”  Modulo-2  addition  (binary  addition  without  carry)  is  used  to 
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compute  the  sum  and  a  parity  bit  is  selected  which  makes  the  parity  for  the  group  even.  The 
same  process  is  repeated  for  each  parity  bit,  thereby  creating  a  7  bit  word.  This  is  the 
encoded  word  which  is  sent  over  the  communication  channel.  Redundant  data  has  been 
added  to  the  word,  so  that  if  no  more  than  one  bit  m  the  seven  is  inverted  due  to  noise,  the 
receiver  will  be  able  to  detect  and  correct  it.  The  receiver  does  this  by  placing  the  received 
word  into  a  buffer  and  extracting  out  the  parity  bits  in  the  form  of  a  3  bit  word.  This  word 


Figure  IV-2:  Parity  bits  for  a  7/4  Hamming  code  [Stevens  93]. 

is  held  in  a  temporary  buffer  until  the  next  step  is  completed,  which  is  done  when  the 
receiver  takes  the  data  bits  from  the  received  word  and  recomputes  the  parity  bits,  just  as 
the  transmitter  did  to  send  the  word  through  the  channel.  The  new  parity  bits  are  then 
X-OReA  (mod-2  addition)  with  the  parity  bits  being  held  in  the  temporary  buffer,  and  if  the 
result  does  not  equal  zero,  the  received  message  has  an  error  at  the  bit  location  specified  by 
the  result  of  the  X-OR.  This  erroneous  bit  is  then  inverted,  and  the  message,  minus  the 
parity  bits,  is  sent  out  of  the  communication  system.  An  example  is  oudined  in  [Stallings 
93]. 
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The  Hamming  code  produced  with  four  data  bits  and  toee  parity  bits  has  only  16  valid 
combinations,  but  with  seven  bits  total,  there  are  128  various  ways  these  seven  bits  can  be 
arranged.  This  leaves  1 12  (128  - 16)  combinations  of  bits  that  are  not  words.  Each  of  the 
1 6  valid  words  are  spread  evenly  throughout  the  invalid  112,  putting  some  space  around 
each  of  the  valid  words.  In  order  to  change  one  valid  word  to  another,  a  certain  number  of 
bits  must  be  inverted.  This  number,  as  mentioned  before,  is  the  Hamming  distance.  In  order 
for  the  code  to  be  able  to  properly  correct  errors  in  a  word,  the  number  of  errors  must  be 
less  than  half  the  minimum  Hamming  distance  of  the  code.  For  example,  in  a  7/4  Hamming 
code,  the  Hamming  distance  is  3.  Half  of  this  is  1.5,  which  means  that  only  one  error  per 
word  can  be  corrected.  However,  2  errors  will  be  detected  but  there  is  no  way  to  determine 
the  original  valid  codeword  because  the  number  of  errors  is  more  than  half  the  Hamming 
distance. 

The  Hamming  distance  between  two  valid  codewords  can  be  increased  by  adding  more 
parity  bits.  Adding  one  extra  parity  bit  to  the  7/4  code  makes  it  an  8/4  code  and  the 
corresponding  Hamming  distance  is  increased  from  3  to  4,  as  shown  in  Table  IV- 1 .  n 


Minimum 

Hamming 

Distance 

Error  Detecting  /  Correcting  Capability 

1 

None 

2 

Single  Error  Detection 

3 

Single  Error  Correction  OR  Double  Error  Detection 

4 

Single  Error  Correction  AND  Double  Error  Detection  OR  Triple 
Error  Detection 

5 

Double  Error  Detection 

Table  IV-1:  Hamming  Distance  vs.  Error  Correction  [Stevens  93]. 


addition,  more  parity  bits  means  more  data  bits  can  be  “covered,  increasing  the  efficiency 
of  the  code,  as  shown  in  Table  rV-2. 
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The  family  of  codes  that  the  Hamming  codes  belong  to  is  the  block  codes.  Other 
members  of  the  block  code  family  include  Reed-Solomon  and 

Bose-Chaudhuri-Hocquenghem  (BCH)  codes.  Another  family  of  codes  also  exists  which 
are  based  on  probabilities  of  errors  occurring.  Studies  of  encoding  and  decoding  from  a 
probabilistic  point  of  view  led  to  the  concept  of  sequential  decoding.  Sequential  codes 
introduced  non-block  codes  of  indefinite  length,  which  are  represented  by  a  tree  and  can  be 
decoded  by  searching  the  tree.  The  most  highly  structured  (and  therefore  the  most  useful,) 


Hamming 

Code 

Dimension 

Number  of 
Parity  Bits 

Number  of 
Data  Bits 

Code  Word 
Length 

Percent 
Redundancy 
(parity/length  X 
100) 

7/4 

3 

4 

7 

43 

15/11 

4 

11 

15 

27 

31/26 

5 

26 

31 

16 

63/57 

6 

57 

63 

10 

127/120 

7 

120 

127 

6 

255/247 

8 

247 

255 

3 

511/502 

9 

502 

511 

2 

1023/1013 

10 

1013 

1023 

1 

Table  rV-2:  Hamming  code  efficiency  as  function  of  number  of  bits  [Stevens  93]. 


of  these  codes  are  called  convolutional  codes.  Convolutional  codes  are  generated  by  linear 
shift-register  circuits  that  perform  a  convolution  operation  on  the  information  stream.  The 
codes  are  usually  decoded  by  a  method  called  the  Viterbi  algorithm.  Both  of  these  methods 
are  summarized  in  Figure  IV-3.  Some  of  the  articles  referred  to  in  this  thesis  documented 
work  which  utilized  convolutional  coders  at  the  modulation  level  and  Viterbi  decoders  at 
the  receiver  end.  [Blahut  83]  proposed  that  both  block  codes  and  convolutional  codes  might 
be  mixed  by  nesting  the  codes.  A  simple  convolutional  code  with  a  Viterbi  decoder  will  do 
fairly  well  at  correcting  occasional  errors  in  a  long  binary  data  stream,  but  too  many  errors 
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occurring  closely  together  will  be  decoded  into  an  error  burst  by  the  Viterbi  decoder.  A 
Reed-Solomon  decoder  on  the  outside  of  the  convolutional  code  can  be  used  to  correct 


these  bursts.  This  technique  of  nesting  a  Reed-Solomon  code  with  a  weak  but  simple 
convolutional  code  has  been  shown  to  be  effective  in  a  channel  that  demonstrates  a 


Gaussian  noise  distribution.  This  concept,  also  known  as  code  concatenation,  was  also 
presented  in  [Proakis  91]  and  results  in  greater  bandwidth  efficiency  than  ordinary  methods 
for  a  given  level  of  performance.This  is  significant  in  underwater  acoustic  communications 
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Figure  IV-3:  Basic  Classes  of  error  correcting  codes  [Blahut  83]. 

because  many  times,  noise  in  an  acoustic  channel  does  much  more  damage  to  a  data  signal 
than  to  cause  occasional  bit  errors.  Some  broadband,  continuous  noise  sources  can  mask  or 
delete  entire  blocks  of  data,  causing  the  receiver  to  receive  nothing,  instead  of  a  damaged 
data  stream.  In  other  words,  the  acoustic  channel  is  not  easily  characterized  as  specific 
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noise  distribution,  but  each  code  must  be  optimized  for  the  particular  conditions  existing  at 
that  location  and  time  of  communication.  Improvements  to  coding  must  be  based  on 
examining  the  noises  present  in  the  environment  and  acoustics.  This  problem  of  lost  or 
non-existent  data  is  not  fully  addressed  in  many  of  the  FEC  codes  available.  Most  of  the 
codes  researched  are  able  to  deal  with  bit  inversions,  but  seldom  are  dropped  or  missing 
chunks  of  data  able  to  be  overcome.  Synchronization  often  depends  on  continuity  of  data 
streams,  and  interruption  of  the  stream  in  an  error  correcting  routine  often  means 
retransmission  is  mandatory.  Unfortunately,  the  underwater  acoustic  channel  is  marked  by 
this  characteristic. 

Future  work  in  the  use  of  FEC  and  error-correcting  codes  needs  to  focus  on  noise 
distribution  affecting  specific  acoustic  devices  so  that  other  codes  can  be  applied  that  are 
better  matched  to  the  noise  characteristics  of  the  environment.  For  example,  noise  due  to 
biologic  sources  is  on  a  much  shorter  time  scale  than  noise  due  to  a  motorboat  passing 
nearby.  Reed-Solomon  and  other  codes  are  likely  to  improve  error  correcting  performance 
in  different  scenarios.  Nevertheless,  computational  complexity  and  the  possibility  of 
complete  dropout  or  lost  synchronization  must  be  addressed.  Hamming  codes  are 
computationally  acceptable  and  good  for  errors  that  are  short  relative  to  encoded  packet 
size.  Convolution  algorithms  that  depend  on  continuous  reception  of  long  strings  of  bits 
may  be  less  robust  in  the  face  of  complete  dropout  or  long  error  bursts. 

D.  OTHER  SOURCES 

[Blahut  83],  [Hamming  86],  [Peterson  72]  and  [Pless  82]  are  all  excellent  texts  on 
error-correcting  codes.  [Proakis  91]  provides  an  advanced-level  overview  of  encoded 
modulation  techniques.  [Gray  94]  presents  an  interesting  discussion  on  existing 
error-encoded  modulation  techniques  and  the  goal  of  building  a  modem  which  incorporates 
FEC.  An  excellent  article  which  focuses  on  Reed-Solomon  codes  is  [Walker  94].  Some 
source  code  is  available  for  experimentation  and  implementation  [Rockliff  91] 

[Flaherty  92].  The  program  in  [Rockliff  91]  is  a  Reed-Solomon  error  detection  /  error 
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correction  routine  that  is  user  configurable  and  comes  with  a  small  demonstration  script. 
The  GNU  ECC.1  program  [Flaherty  92]  also  implements  a  Reed-Solomon  algorithm, 
which  can  correct  three  byte  errors  in  a  block  of  255  bytes  and  detect  more  severe  errors. 

E.  OTHER  CONSIDERATIONS 

1.  Character  Strings 

At  the  physical  level,  the  signals  carried  by  most  media  represents  binary  data  because 
the  digital  signals  in  the  computer  actually  represent  ones  and  zeros.  All  digitized  data, 
(whether  video,  audio,  or  text)  can  be  represented  by  ones  and  zeros.  However,  text  is  very 
easy  to  represent  in  an  encoded  fashion.  Character  strings  can  be  used  for  encoding  because 
any  data  set  can  be  represented  by  them.  Any  file  (including  binary  sound  or  video  files  can 
be  encoded  in  8-bit  ASCII.  For  example,  the  Unix  operating  system  supports  uuencode,  a 
program  which  converts  a  binary  file  into  an  ASCII-encoded  representation  that  can  be  sent 
using  mail.  ASCII  can  also  easily  be  encoded  with  an  error-detection  /  error-correction 
routine.  It  is  important  to  note  that  8-bit  ASCII  rather  than  the  more  common  7-bit  ASCII 
must  be  supported.  Although  some  input  devices,  such  as  keyboards,  do  not  support  the  full 
256-character  8-bit  ASCE  set,  8-bit  ASCD  is  essential  if  arbitrary  binary  data  is  to  be 
represented.  [Turner  94]  discusses  the  use  of  ASCII  in  designing  a  language  for 
cooperating  AUVs.  This  allowed  operators  to  assess  system  state,  since  messages  passed 
between  units  were  observed  on  a  regular  PC  monitor,  rather  than  having  to  record  binary 
communication  data  and  translate  it  into  readable  messages. 

2.  Encryption  for  Reliability  and  Security:  DES 

Military  AUV  applications  sometimes  include  operations  where  the  AUV  is  capable 
of  extending  the  tactical  reach  of  a  surface  ship  or  submarine.  In  situations  such  as  this, 
security  and  resistance  to  interception  is  vitally  important  Although  acoustic 
communications  are  by  their  very  nature  open  and  easily  intercepted  by  anyone  with  the 
right  equipment,  the  data  represented  by  the  acoustic  signals  can  easily  be  encrypted.  The 
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Data  Encryption  Standard  (DES)  has  been  proposed  for  AUV  applications  due  to  the  ease 
of  implementation  and  the  level  of  security  provided  [Brutzman  92].  Furthermore,  the  DES 
Electronic  Code  Book  (ECB)  method  is  ideally  suitable  for  AUV  application  because  it 
uses  short  blocks  of  data  that  are  not  chained  to  a  preceding  or  following  data  block  and 
does  not  require  frequent  confirmation  handshaking.  FEC  algorithms  are  well-suited  to 
working  with  encryption  algorithms,  before  or  after  the  encryption  takes  place.  Encryption 
algorithms  are  designed  to  add  randomness  to  a  data  stream.  Many  FEC  algorithms  actually 
add  structure  to  data  stream,  which  is  exactly  what  encryption  algorithms  are  trying  to 
negate.  However,  FBC  can  be  added  prior  to  encryption,  and  encrypted  along  with  the  data. 
This  will  protect  the  randomness  of  the  data,  and  assuming  the  message  is  received  within 
the  bounds  of  the  decryption  algorithm,  the  FEC  algorithm  will  protect  the  data  inside  the 
encrypted  packet  until  it  is  decoded. 

3.  Compression  For  Efficiency 

[Hoag  94],  [Walker  94]  and  [Turner  94]  all  mention  use  of  compression  algorithms  to 
reduce  data  volume  necessary  to  transfer  data  between  autonomous  units.  In  many  ways, 
these  algorithms  work  hand  in  hand  with  FEC  algorithms,  which  sounds  ironic  in  that 
compression  algorithms  are  intended  to  compact  data  whereas  FEC  algorithms  increase 
redundancy  of  that  same  data.  However,  there  is  a  optimal  balance  between  the  two 
operations  which  must  be  reached  in  order  to  achieve  the  best  performance  from  the 
encoding  method  as  a  whole.  This  is  done  by  possible  compression  of  the  data  packets  prior 
to  reaching  the  layers  following  and  expansion  of  the  data  after  reception  prior  to  passing 
up  to  the  next  higher  level.  FEC  coding  is  effected  at  the  physical  layer,  thus  FEC  is 
operating  on  data  that  has  been  compressed  already.  It  doesn’t  matter  to  FEC  what  the  data 
is,  as  long  as  it  is  able  to  add  redundancy  in  an  optimal  method  that  is  better  than  that  gained 
by  compression  and  no  FEC. 
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F.  SUMMARY 


Data  communications  are  most  vulnerable  to  errors  while  in  the  channel  between 
sender  and  receiver.  Adding  data  redundancy  in  the  form  of  forward  error  correction  can 
help  the  receiver  repair  the  damaged  data,  up  to  Umits  which  are  at  the  discretion  of  the 
programmer.  Errors  in  excess  of  this  level  will  require  retransmission.  Various  encoding 
methods  are  available,  and  most  fall  into  either  block  or  non-block  classes.  Block  codes  are 
implemented  using  variations  of  Hamming  codes  or  Reed-Solomon  routines.  Non-block 
codes  are  weaker  than  block  codes,  but  are  capable  of  being  “nested”  inside  a  stronger 
block  code  to  maximize  efficiency  and  speed.  ASCII  text  is  ideally  suited  for  encoding 
applications,  due  to  its  ability  to  represent  various  other  data  forms,  such  as  binary  data, 
sound,  or  video.  Data  encryption  and  data  compression  are  both  data-manipulation 
processes  which  can  benefit  from  the  reliability  provided  by  EEC. 
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V.  TOWARD  INTERNET  PROTOCOL  OVER  SEAWATER  (IP/SW) 

A.  INTRODUCTION 

Reliability  of  underwater  acoustic  communications  can  be  improved  by  implementing 
forward  error  correction  coding,  but  unless  higher  level  protocols  are  introduced  into  the 
acoustic  communications  channel,  all  that  will  have  been  accomplished  is  the  creation  of  a 
point-to-point  link.  Although  that  in  itself  is  needed,  the  IP  communications  model  is  based 
on  networks  where  multiple  computers  are  communicating  among  each  other  and 
communcations  directed  at  hosts  outside  the  immediate  network  are  directed  out  via  a 
specific  host,  or  gateway.  The  function  or  purpose  of  Internet  Protocol  is  to  move 
datagrams  (packets)  through  an  interconnected  set  of  networks  [Postel  81].  In  this  section, 
reasons  for  networking  underwater  acoustic  devices  are  presented,  and  what  work  must  be 
done  before  IP  communications  can  be  realized  over  an  acoustic  channel.  We  call  the  result 
of  this  process  IP  over  Seawater  (IP/SW).  Methods  of  implementation  are  presented, 
including  reconunendations  for  initial  experimentation  with  existing  serial  line 
point-to-point  protocols. 

B.  NETWORKING  APPROACHES  TO  COMMUNICATIONS 

A  networked  approach  divides  the  detailed  functionahty  of  computer  communications 
into  well-defined  layers.  One  common  model  is  the  four  layers  of  the  Internet  Protocol  (IP) 
suite  [lAB  94]  [Stallings  94]  described  in  Chapter  11.  The  IP  model  is  more  a  loose 
hierarchy  of  functionality  than  a  strictly  separated  set  of  layers  in  that  interlayer 
communication  is  not  restricted  to  adjacent  levels.  Simplified  descriptions  of  the  functional 
characteristics  of  the  four  IP  layers  appears  in  Figure  II-4,  and  a  represenation  of  the  logical 
content  of  IP  datagrams  is  shown  in  Figure  V-1.  It  is  interesting  to  note  that  the  media  for 
commonly  understood  physical  and  transport  layer  network  standards  have  high 
propagation  speeds,  high  bandwidth  capacities  and  low  noise  (e.g.  Ethernet,  FDDI,  ATM 
etc.).  This  means  that  the  design  of  corresponding  protocols  can  essentially  ignore  the 
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temporal  costs  of  retransmission.  Such  a  situation  is  not  the  case  in  noisy,  slow  propagation 
and  low  bandwidth  environments.  However,  many  similar  transmission  problems  have 
been  addressed  and  solved  using  a  networked  approach  in  other  media  and  environments. 
In  particular,  internetworking  solutions  have  been  proposed  and  achieved  for  wireless 
environments  such  as  packet  radio  [Chen  94]  and  satellite  [Jabbari  94].  Investigations  into 
internetworking  for  seawater  will  gain  much  by  evaluating  the  balance  struck  m  these  other 

network  domains.  An  example  is  wireless  LANs. 

■Wireless  LANs  are  usually  set  up  in  either  a  broadcast  (flooding)  structure  or  a 
structured  packet-passing  scheme.  Broadcast  systems  simply  receive  packets,  examine 
them  to  see  if  the  address  is  theirs,  and  if  not,  they  retransmit  the  packet.  In  this  system, 
channel  utilization  is  low,  but  implementation  is  easy.  CSMA,  ALOHA,  or  slotted  ALOHA 
are  common  examples  of  this  system.  Packet  passing  systems,  which  elect  a  spokesman  to 
act  as  a  base  station,  are  network-intensive  due  simply  to  maintaining  the  spokesman. 
However,  most  wireless  systems  have  a  structured,  pre-existing  high-speed  network  that 
they  are  tied  into,  and  traffic  within  a  small  wireless  system  can  be  grouped  into  two 
directions;  upUnk  (into  the  high-speed  existing  network)  or  downlink  ( from  the  high-speed 
network  into  the  wireless  network).  Access  points  are  nodes  on  the  high-speed  network 
which  connect  to  the  wireless  network,  usually  base  stations  or  repeaters.  More  often  than 
not,  downlink  communications  are  broadcast  from  the  access  point  to  the  entire  network  on 
a  common  channel.  This  presents  a  problem  if  one  or  more  stations  did  not  receive  the 
transmission  correctly.  If  the  message  was  not  for  them,  they  would  not  know  that  it  was 
not  intended  for  them  if  the  address  was  the  part  they  did  not  receive.  Therefore,  they  would 
NAK  and  the  whole  transmission  would  have  to  be  repeated  needlessly.  This  could  happen 
many  times  before  all  stations  received  the  message  correctly.  An  alternative  is  either  to 
multicast  each  message  multiple  times,  incrementing  a  sequence  number  so  that  the 
receivers  have  to  receive  the  message  correctly  only  once,  or  else  to  not  requu-e 
acknowledgements  from  the  wireless  nodes.  This  is  an  example  of  an  unreliable  delivery 

scheme. 
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As  can  be  seen,  many  of  the  problems  which  plague  the  wireless  LAN  designers  are 
the  same  as  those  which  underwater  acoustic  networks  must  contend  with,  except  the  stakes 
are  higher  and  the  failure  of  a  node  is  not  easily  rectified  as  in  a  wireless  mobile  LAN. 

Acoustic  networks  must  have  a  medium  access  control  protocol  which  maximizes 
throughput,  not  bit  rate.  In  addition,  operating  throughput  is  practically  more  important 
than  theoretical  throughput,  a  metric  which  is  all  too  often  used  to  determine  network 
operating  health.  Requirements  for  an  acoustic  network  MAC  protocol  are  much  the  same 
as  those  listed  for  a  wireless  network  in  [Chen  94]  and  are  listed  in  Figure  V-2.  Of 
particular  note  is  the  segregation  of  most  MAC  protocols  into  three  distinct  groups:  random 
access  such  as  CSMA,  CSMA-CD,  or  ALOHA,  polling,  such  as  described  in  [Chen  94], 
[Bharghavan  94]  and  [Catipovic  93],  and  time  division  multiple  access.  Most  work  in 
wireless  MAC  protocols  seems  to  be  focusing  on  polling,  and  it  is  not  surprising  that 
acoustic  LAN  efforts  are  not  directed  in  the  same  direction.  The  ALAN  described  in 
[Catipovic  93]  requires  the  access  point  to  resolve  multiple  transmit  request  messages  from 
contending  nodes,  and  sort  them  over  time.  This  places  the  burden  of  receiving  overlapping 
and  competing  transmissions  on  the  access  point,  when  in  conventional  networks  none 
would  be  serviced.  Each  transmitter  would  simply  back  off  and  retransmit  and  hope  for 
success.  This  is  an  example  of  a  protocol  which  utilizes  advancements  in  hardware  to 
perform  layer  functions.  It  will  be  interesting  to  see  how  this  system  performed. 

C.  TOWARDS  IP  OVER  SEAWATER  (IP/SW) 

Extensions  to  IP  have  been  established  over  many  disparate  media.  The  most 
fundamental  principle  for  establishing  IP  compatibility  among  acoustic  telemetry  devices 
is  to  specify  data  link  and  network  physical  layer  functionality.  This  will  consist  of  physical 
control,  medium  access  control  (MAC)  and  logical  link  control  (LLC).  If  interfaces  are 
properly  designed,  it  will  be  feasible  to  use  acoustic  modems  and  their  supporting 
controllers  in  the  same  way  as  a  LAN  interface  card  plugged  into  a  personal  computer. 
Underwater  acoustic  devices  might  then  be  considered  replaceable  parts.  The  functionality 
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of  different  types  of  acoustic  modems  can  be  interchangeable  as  long  as  all  the  modems 
utilizing  a  single  acoustic  link  are  acoustically  compatible.  Although  it  may  not  be  possible 
to  permit  direct  control  of  the  physical  layer  by  upper  layers,  such  functionality  is  optional 

under  IP  and  is  not  always  present  in  other  network  media. 

Layer  functionality  may  have  to  be  revised  in  the  light  of  MAC  and  LLC  protocols, 
depending  on  advances  in  hardware.  This  idea  is  represented  in  Figure  V-3.For  example, 
with  DSP  taking  a  significant  portion  of  available  power,  existing  layer  functionality  may 
have  to  be  modified  by  reducing  or  eliminating  some  or  all  of  a  particular  layer,  depending 
on  what  functions  that  layer  contributes.  Some  of  the  functions  are  not  needed  in  an 
acoustic  network,  considering  the  up-link  /  down-link  characteristics  of  this  type  of 
network.  Internet  address  resolution,  done  at  the  IP  level,  will  probably  be  done  by  the 
access  point  using  a  hash  or  lookup  table  and  then  sending  a  modified,  shortened  address 

to  wake  up  that  particular  node. 

Multiple  ALANs  might  operate  simultaneously  in  close  proximity  through  frequency 
band  separation.  The  underwater  acoustic  channel  is  a  shared  medium.  In  this  respect 
transmitted  messages  can  usuaUy  be  considered  broadcast,  since  all  compatible  devices 
will  hear  a  transmission  and  be  required  to  process  it  prior  to  determining  packet  address. 
If  multiple  acoustic  channels  are  used,  the  acoustic  channel  is  analogous  to  a  multicast 
channel  since  individual  devices  are  likely  to  ignore  frequency  bands  that  are  not  of 
interest.  Given  that  bandwidth  is  low  and  temporal  latency  high  over  a  single  acoustic 
channel,  the  use  of  multicast  and  multiple  frequency  approaches  will  primarily  be  used  to 
increase  effective  bandwidth.  We  estimate  that  current  microprocessors  typically  have 
adequate  computational  capacity  to  process  several  acoustic  telemetry  channels 
simultaneously.  Multiple  frequency  bands  can  be  particularly  useful  for  a  single 
communications  channel.  Since  blanking  occurs  when  a  transducer  is  transmitting, 
followed  by  a  short  period  of  time  when  local  reverberation  prevents  effective  reception, 
an  acoustic  channel  might  effectively  be  considered  half-duplex.  More  efficient 
acknowledgment/negative  acknowledgment  (ACK/NAK)  schemes  use  multiple  frequency 
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bands.  Given  that  the  source  power  requirements,  propagation  paths  and  attenuation  of 
sound  in  water  are  all  highly  dependent  on  frequency,  and  given  that  one  host  may  be 
sending  much  more  data  than  another,  it  is  likely  that  out  of  two  frequency  bands,  one  is 
better  suited  for  transmission  and  will  therefore  be  dedicated  to  the  host  that  is  the 
predominant  transmitter. 

One  lesson  demonstrated  repeatedly  in  network  protocol  development  is  that 
individual  protocols  in  theory  may  appear  efficient,  but  in  practice  can  incur  excessive 
overhead  when  combined  with  other  layers  of  the  protocol  hierarchy.  Current  acoustic 
telemetry  devices  operate  independent  of  any  other  network  connectivity  present  at  the  host 
computer.  It  is  likely  that  new  trade-offs  and  optimizations  will  be  necessary  when  existing 
acoustic  telemetry  protocols  are  adapted  for  IP/SW  compatibility.  Packet  content  may  also 
require  redesign,  in  order  to  incorporate  the  functions  shown  in  Figure  V-4.  In  other 
transmission  media,  a  networking  approach  to  communications  architecture  development 
has  repeatedly  produced  overall  improvements  that  are  better  suited  to  user  requirements 
than  specialized  protocols.  One  additional  point  is  that  delivery  of  individual  acoustic  IP 
packets  need  not  always  be  reliable.  The  Internet  transport  layer  provides  for  both  reliable 
(TCP)  datagrams  and  unreliable  best-effort  (UDP)  datagrams.  Currently  unreliable 
delivery  is  the  norm  in  acoustic  telemetry  devices.  Adding  reliable  delivery  without 
requiring  unacceptably  expensive  retransmission  schemes  is  an  essential  prerequisite  for 
development  of  IP/SW.  Because  all  hosts  on  the  internet  are  not  able  to  connect  to  a  specific 
IP  address  on  an  acoustic  network,  a  gateway  is  needed  which  knows  the  IP  addresses  of 
all  the  acoustic  hosts  and  can  strip  the  IP  headers  off  the  packets  intended  for  that  host.  It 
can  then  use  a  host  table  or  lookup  table  to  find  the  host’s  unique  address,  much  in  the  same 
way  a  router  finds  an  Ethernet  address. 

D.  IMPLEMENTATION 

Although  true  acoustic  networks  will  not  be  realized  without  MAC  layer  funtionality, 
one  must  walk  before  running.  Even  with  forward  error  correction,  a  protocol  at  the 
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physical  layer  for  transmitting  and  receiving  data  is  still  necessary.  Several  protocols 
already  being  utilized  are  the  Serial  Line  Internet  Protocol  (SLIP)  [Romkey  88]  or 
Point-to-Point  Protocol  (PPP)  [Simpson  92]  [Simpson  94].  These  protocols  are  utilized  by 
hosts  connected  to  the  internet  by  a  serial  line,  and  are  used  for  passing  Internet  packets 
through  the  telephone  lines.  All  SLIP  does  is  define  a  sequence  of  characters  that  frame  IP 
packets  on  a  serial  line,  and  nothing  more.  It  provides  no  addressing,  which  is  done  at  the 
IP  level,  nor  packet  type  identification  or  error  detection/correction  or  compression. 
Because  it  does  so  little,  though,  it  is  simple  and  easy  to  implement.  As  most  serial  lines  are 
point-to-point  links,  it  is  reasonable  that  the  network  protocol  proposed  for  an  acoustic 
network  which  is  intended  to  utilize  SLIP  should  make  maximum  use  of  a  point-to-point 
routing  mechanism. 
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Figure  V-1:  Logical  content  of  a  IP  packet. 
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duplex  channel  is  easily  acquired  with  two  pairs  of  modems,  described  in  Chapter  H,  set  to 
two  different  frequencies.  As  long  as  frequency  selectivity  is  of  sufficient  quality  to  avoid 
cross-channel  interference,  a  point-to-point  duplex  link  is  possible.  Even  with  low-cost 
DiveTracker  units  running  a  modem  program,  this  protocol  is  ideally  suited  for  initial 
testing. 

Determination  of  an  optimum  spreading  of  functionality  throughout  the  IP  stack  is  a 
viable  area  of  study  for  IP  over  Seawater.  Some  functions  should  be  implemented  at  every 
layer,  and  others  need  only  be  used  at  one.  Determination  of  which  function  at  which  layer 
can  only  be  determined  by  testing. 

E.  SUMMARY 

As  functionality  is  moved  from  the  upper  levels  down  towards  the  physical  layer, 
much  of  what  is  done  in  software  is  able  to  be  implemented  in  hardware.  As  algorithms 
mature,  hardware  advances  parallel  the  applications  and  are  able  to  increase  speed 
accordingly.  Whether  in  software  and  using  faster  processors,  or  in  hardware  and  using 
slower  processors,  IP  over  SW  is  possible  either  way.  The  Internet  Protocol  is  flexible  and 
able  to  be  modified  to  meet  the  environment  it  is  tailored  to  operate  in.  Specific  challenges 
to  IP  over  Seawater  will  include  the  medium  access  problem  and  retransmissions  if 
contention  is  encountered.  These  retransmissions  have  nothing  to  do  with  messages 
received  in  error,  because  they  are  simply  collisions.  Hardware  capable  of  resolving  such 
collisions  may  become  available,  but  other  alternatives  such  as  polling  are  viable  options 
and  should  be  subjected  to  further  testing.  Optimization  of  layer  functionality  will  result  in 
a  trimmed-down,  efficient  protocol  structure  which  embeds  redundancy  where  it  is  needed 
and  eliminates  excess  baggage  where  not  needed.  Results  of  this  optimization  can  be 
implemented  in  a  modified  packet  structure,  as  long  as  standards  organizations  can  agree 
on  what  is  required  and  what  is  optional. 
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VL  EXPERIMENTAL  SETUP  AND  RESULTS 


A.  INTRODUCTION 

No  research  is  complete  without  experimentation,  and  research  in  acoustic 
communications  is  no  different.  This  section  describes  the  work  completed  in  proving  the 
efficacy  of  forward  error  correction  to  reduce  the  need  for  retransmissions  of  a  message 
received  in  error.  First,  a  computer-to-computer  simulation  is  described,  which 
implemented  a  error-injection  routine  into  a  stream  serial  data.  Second,  results  of  in-water 
tests  both  in  the  laboratory  and  in  the  North  harbor  of  Moss  Landing  using  DiveTracker 
diver  communication  devices  as  modems  are  reported. 

B.  SETUP 

The  experimental  goal  of  this  thesis  is  to  show  the  effectiveness  of  a  12/8  Hamming 
error-correcting  code  in  comparison  to  transmission  without  forward  error  correction.  The 
data  was  obtained  in  two  separate  steps.  The  first  step  was  to  create  a  Hamming 
encoder/decoder  and  run  it  on  two  personal  computers  to  demonstrate  the  effectiveness  of 
forward  error  correction.  Acoustic  noise  was  simulated  by  assuming  that  no  more  than  one 
bit  in  8  (or  one  bit  in  16)  was  affected  by  error  and  was  inverted.  This  was  done  to  simulate 
a  10%  data  error  rate,  a  fairly  typical  value  for  an  underwater  system  operating  at  the 
boundaries  of  usefulness  [Flagg  95].  Long  series  of  errors  corresponding  to  acoustic 
transients  such  as  overhead  shipping  are  a  special  case  and  were  not  specifically  evaluated. 
Different  FEC  codes  can  be  applied  to  ameliorate  long-duration  error  bursts  and  are  an 
excellent  topic  for  future  experimental  work. 

In  preparation  for  in-water  testing  using  DiveTracker  acoustic  modems  [Flagg  95], 
data  encoding  software  was  adapted  for  end-to-end  testing  using  two  PCs  connected  by  null 
modem  cables  via  serial  ports.  The  test  equipment  and  data  flow  diagram  appears  in  Figure 
VI- 1.  The  only  difference  between  the  in-water  rig  and  the  simulation  rig  is  absence  of  the 
DiveTracker  sonar  devices  and  the  insertion  of  synthetic  noise  during  simulation. 
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An  initial  test  scenario  called  for  100  repetitions  of  a  fifty  character  message,  Th£ 
purpose  of  computing  is  insight,  not  numbers!!”  [Hamming  86].  Transmission  of  a  fixed 
character  string  parallels  the  testing  of  modems  described  in  [Garmer  92].  Measures  of 
effectiveness  included  correct  operation  of  the  Hamming  encoder/decoder  routines  in  the 
presence  of  single  bit  errors,  percentages  of  garbled  messages  corrected  at  the  receiver, 
(H/A),  and  percentage  of  garbled  messages  uncorrectable  at  the  receiver  which  would 
require  retransmission  to  receive  correctly.  Simulation  term  definitions  appear  in  Table 
VI- 1.  The  second  test  was  to  actually  use  an  acoustic  modem  to  duplicate  this  scenario 
while  passing  data  through  water  and  observe  the  effect  of  the  error-correction  code  on  data 
transmission. 

C.  HAMMING  ENCODER/DECODER  SIMULATION 

The  experiment  used  Hamming  12/8  double-error  detecting/single-eiror  correcting 
code  with  even  parity,  which  means  12  bits  total  were  used  to  encode  8  bits  of  message 
using  4  bits  for  parity.  These  values  were  selected  because  8  bits  corresponds  to  a  single 
byte  and  a  byte-base  coding  algorithm  was  desired  for  the  reasons  discussed  in  Chapter  IV. 
Double-error  detecting  indicates  that  a  single  bit  or  double  bit  error  out  of  the  12  total  bits 
can  be  detected.  Three  bits  or  more  in  error  out  of  12  are  likely  to  produce  an  internally 
consistent  result  which  cannot  be  detected  by  this  code.  Single-error  correcting  implies  that 
any  single  bit  in  error  out  of  the  12  can  be  corrected  using  the  redundant  information  present 
in  the  parity  bits.  Figure  Vl-2  shows  how  message  bits  and  parity  bits  are  combined  to 
convert  two  uncoded  message  bytes  into  three  Hamming-encoded  message  bytes.  Thus  two 
uncoded  8-bit  ASCII  characters  are  represented  by  three  encoded  8-Bit  ASCII  characters. 
Even  parity  implies  that  any  valid  combination  of  message  bits  and  parity  bits  must  add 
(modulo  2)  to  zero;  The  actual  code  was  derived  from  [Hamming  86]  and  is  listed  in 
Appendix  A.  The  Hamming  encoder/decoder  routines  proved  correct  for  all  cases  in  a  wide 
variety  of  test  strings,  some  of  which  included  special  8-bit  ASCII  characters  to  show 
general  applicability  to  arbitrary  binary  data.  Simulation  results  in  appear  in  Table  VI-2. 
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Data 

Point 


Description 


Character 

Counts, 

Percentages 


Original  string  sent  by  user 


Total  bytes  for  Hamming 
encoded  characters 


DiveTracker  pulse-position 
coding  adds  synchronization  to 
two  bytes  +  checksum,  if  on 


Noise  added  during  acoustic 
transmission,  propagation,  and 
reception 


DiveTracker  pulse-position 
coding  delivers  two  bytes 


1  out  of  8  or  1  out  of  16  bits 
eligible  for  error 


Probability  that  a  single  bit  is  in 
error 


Errors  induced  (in  water  or 
simulation) 


Flags  marking  characters  with 
errors  detected 


Hamming  (decoded-only) 
uncorrected  characters 


Hamming  corrected  characters 


Undetected  /  uncorrected  errors 


%  received  characters  in  error 
prior  to  applying  correction 


%  characters  correct  and 
corrected 


Comments 


Simulation 
tests  replace 
C/D/E  with  1 
in  8  or  1  in  16 
random 
position  bit 


“The  purpose  of  computing  is 
insight,  not  numbers!! 


Parity  bits  added,  12/8  code 
increases  total  size  by  50%. 


Synchronization  of  pulse  is 
essential. 


Empirical  noise  distributions  will 
be  far  more  complex. 


DiveTracker  checksum  error 
causing  retransmit  will  be 
disabled  during  in-water  tests. 


Arbitrary  noise  probability 
function.  Position  of  error  bit  in 
byte  is  also  random. 


One  or  more  bits/byte,  unknown 
by  receiver. 


Detects  single,  double,  and 
multiple  bit  errors. 


Original  sentence  restored, 
transmission  errors  still  present 


Assumes  only  single  error 
corrected 


Unknown  by  receiver. 


Expected  retransmission 
needed  if  EEC  not  used. 


Overall  EEC  robustness. 


Table  VI- 1:  Explanation  of  simulation  parameters. 


Dive  Tracker  interface  boxes  and  in-water  hydrophones 
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m-message  bit,  p-parity  bit,  a-first  byte,  b-second  byte 

mg.  m,.  ni«,  ms,  p,,  m,,  m3,  nia,  P3,  m^p^^p., 

^8b  ^7b  ^5b  P^b  ^b  *^3b  ^b  Psb  ^Ib  P2b  Plb 

16  message  bits  -  2  uncoded  message  bytes 
+  8  parity  bits  -  3  encoded  message  bytes 


Figure  VI-2: 12/8  Hamming  code  structure. 

Generation  of  the  encoder  and  decoder  was  done  in  the  C  programming  language.  This 
language  was  used  mainly  because  of  the  large  amount  of  existing  code  available  which 
was  needed  to  implement  the  encoder-decoder  on  a  PC  using  serial  communications.  This 
is  also  compatible  with  DiveTracker,  NPS  AUV,  and  other  underwater  robot  software 
environments.  The  C  programming  language  was  learned  outside  of  class  using  [Aitken 
94],  It  was  found  to  be  nearly  impossible  to  learn  a  language  such  as  this  without  the  help 
of  someone  familiar  with  the  language  to  clarify  points  of  confusion,  of  which  there  were 
many.  Pointers  were  difficult  to  learn  and  use  properly.  It  was  found  that  an  understanding 
of  the  concepts  of  data  representation  in  C  is  critical  for  effective  use  of  bitwise  operators 
and  type  conversions.  A  Borland  C++  compiler  was  installed  on  a  PC  for  use  in  compiling 
the  code  for  the  encoder/decoder,  since  it  was  to  run  on  a  PC. 
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The  program  evolved  by  first  using  a  main  function  which  passed  a  string  of  text  to  an 
encoder  function.  The  encoder  produced  a  string  1.5  times  larger  than  the  input  string,  due 
to  the  additional  Hamming  parity  bits  embedded  in  each  of  the  encoded  characters.This 
array  was  then  passed  to  an  error  simulation  function,  which  injected  random  errors  into 
the  array  of  text  to  be  transmitted.  The  encoded  text,  now  containing  errors,  was  passed  to 
a  decoder  function,  which  read  it  in  and  corrected  the  errors  as  they  were  encountered  on  a 
character-by-character  basis.  The  input  string,  the  transmitted  string,  the 
erroneous-received  string,  and  finally,  the  corrected  received  string  were  displayed  on  the 
video  monitor.  The  code  was  then  separated  into  two  different  functions  for  respective 
operation  on  a  transmitter  and  a  receiver.  This  test  setup  is  shown  in  Figure  VI-3. 


Figure  VI-3:  Initial  test  setup  for  error  simulation. 

D.  COMPUTER  SETUP 

A  null-modem  serial  cable  was  attached  between  the  two  computer’s  serial 
communication  ports.  Null  modem  cables  are  required  whenever  two  DTEs  are  required  to 
communicate  between  each  other  because  of  the  way  their  communications  ports  are 
designed.  Each  DCE  is  designed  to  be  paired  with  a  DTE,  and  their  mechanical  and 
electrical  characteristics  are  such  that  a  standard  serial  cord  will  suffice  to  do  the  job. 
However,  when  two  DTEs  are  joined  using  a  DTE-DCE  cord,  the  transmit  line  of  one  DTE 
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will  be  attempting  to  communicate  with  the  other’s  transmit  line  instead  of  its  receive  line 


Data 

Point 


Description 


Original  string  sent  by  user: 


Total  bytes  for  Hamming  encoded 
characters 


DiveTracker  pulse-position 
coding  adds  synchronization  to 
two  bytes  +  checksum,  if  on 


Noise  added  during  acoustic 
transmission,  propagation,  and 
reception 


DiveTracker  pulse-position 
coding  delivers  two  bytes 


1  out  of  8  or  1  out  of  16  bits 
eligible  for  error 


Probability  that  a  single  bit  is  in 


Errors  induced  (in  water  or 
simulation) 


Flags  marking  characters  with 
errors  detected 


Hamming  (decoded-only) 
uncorrected  characters 


Hamming  corrected  characters 


Undetected  /  uncorrected  errors 


%  received  characters  in  error 
prior  to  ^plying  correction 


%  characters  correct  and 
corrected 


Character  counts,  percentages 


5000  4000 


7500  6000 


728  1084 


15.0%  27.1% 


99.5%  98.1% 


Table  VI-2:  Simulation  Results 

Hence,  a  device  to  allow  the  transmit  line  of  one  computer  to  communicate  with  the  receive 
line  of  the  other  is  needed.  This  device  is  called  a  “Null-Modem.”  A  null-modem  cable 


differs  from  a  simple  extension  cable  in  the  way  that  the  two  ends  are  connected  in  order 
to  allow  two  computers  to  communicate  with  each  other  using  an  RS-232  interface.  In 
addition  to  connecting  the  two  computers  correctly,  there  are  a  couple  of  additional  steps 
that  must  be  completed  before  the  computers  can  communicate.  One  of  these  involves 
configuration  of  Interrupt  Requests  (IRQ).  Interrupts  are  addresses  where  the  CPU  looks  to 
see  if  there  are  any  waiting  tasks  that  must  be  serviced.  In  setting  up  a  serial 
communications  program,  the  serial  port  must  be  configured  with  the  proper  IRQ  number. 
Complete  details  on  this  approach  can  be  found  in  numerous  references  including 
[Campbell  87]. 

E.  ACOUSTIC  COMMUNICATION  WITH  DIVETRACKER:  AMODEM 

DiveTracker  diver  navigation  and  Communication  devices  described  in  Figure  II-7  and 
Figure  11-8  were  used  as  acoustic  modems.  The  DiveTrackers  were  loaded  with  a  program 
called  AMODEM  DC  which  takes  two  bytes  at  a  time  from  an  RS-232  serial  line  and 
transmits  them  in  a  20  bit  word  using  MFSK.  AMODEM  is  user  configurable  for  the 
parameters  listed  in  Table  VI-3.  Appendix  B  explains  how  the  code  is  loaded  into  the  two 
DiveTrackers  and  executed.  The  receiving  units  then  export  the  two  received  bytes  out  to 


Speed 

Power 

Pulse  Length 

Gain 

Threshold 

Filter 

Checksum 

0-4 

000-255 

0100-5000 

0-3 

0-99 

0-5 

0/1 

(0  =  25  bps) 

(1  =  64  bps) 

(2  =125  bps) 
(3  =  250  bps) 

(%  of  duty  cycle 
of  the  driver 
waveform) 

(0  =  0%) 
(255=50%) 

(microseconds) 

(lOdB 

over 

previous 

step) 

(Every  10 
decreases 
sensitivity 
by6dB) 

Filter 

ID 

Off/On 

1 

255 

1000 

3 

16 

0 

1 

Table  VI-3:  AMODEM  default  power-on  parameters  [Flagg  95]. 


their  respective  personal  computers  running  a  terminal  program.  The  Hamming  code  which 
had  been  installed  on  the  PCs  for  the  previous  test  is  then  executed.  It  is  important  to  note 
that  the  speed  on  both  modems  must  be  set  the  same,  or  communications  will  be  garbled. 
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In  all  the  tests  run  with  the  Hamming  code,  the  Checksurn  feature  was  turned  OFF.  The 
default  power-on  settings  of  AMODEM  were  left  alone,  with  the  exception  of  the  power 
settings  which  were  reduced  to  10  for  most  of  the  tests. 


Figure  ¥1-4:  DivelVacker  Setup  in  AUV  Test  Tank 


F.  AUV  TEST  TANK 

The  first  tests  of  the  Hamming  encoder/decoder  using  the  DiveTracker  modems  was 
done  in  the  NFS  AUV  laboratory  test  tank  as  shown  in  Figure  VI-4.  This  tank  is  an 
above-ground  structure  made  out  of  steel,  20  feet  long  and  20  feet  wide,  8  feet  in  depth.  The 
transducers  were  initially  hung  in  the  tank  with  about  6”  separation  between  them.  The 
terminal  program  was  executed,  but  no  data  was  displayed  by  the  receiving  computer. 
Various  power  levels,  pulse  lengths,  and  threshold  parameters  were  all  attempted,  but  no 
connection  was  made.  To  verify  correct  operation  of  the  system,  the  transducers  were  taken 
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out  of  the  tank  and  put  into  a  bucket  of  water.  Data  was  transmitted  and  received  in  the 
bucket  without  any  problems,  leading  to  the  determination  that  the  steel  tank  had  too  much 
reverberation  and  ringing  for  effective  acoustic  communications. 

Previous  experiments  with  the  DiveTracker  being  used  for  AUV  location  and 
navigation  in  the  test  tank  had  also  met  with  limited  success,  due  to  the  extreme 
interference  experienced  from  reflected  waves.  Acoustic  telemetry  in  a  tank  construct^ 
such  as  this  was  found  to  be  nearly  impossible,  due  to  the  reverberations  and  echoes  that 
occur  off  the  steel  walls  of  the  tank.  Further  test  showed  that  communications  were  possible 
when  using  greatly  reduced  power  levels  and  longer  blanking  intervals. 

G.  THE  TEST  PIPE 

After  Ending  that  the  test  tank  would  not  support  data  communications,  a  different 
approach  was  taken.  Due  to  the  difficulty  of  moving  the  AUV,  which  had  the  DTI -Mod 
DiveTracker  module  enclosed  within  it,  to  a  suitable  test  location,  a  test  pipe  was  set  up  to 
create  an  acoustic  channel.  The  fost  attempt  used  35  feet  of  2  inch  diameter  PVC  pipe 
shaped  like  a  U  with  90  degree  elbows  on  each  end,  all  filled  with  water.  Unfortunately, 
data  could  not  be  passed  in  this  pipe  at  all.  The  next  approach  used  a  35  foot-long  section 
of  4”  PVC  pipe,  with  90  degree  elbows  on  each  end  and  filled  with  water.  This  setup 
worked  well  and  is  shown  in  Figure  VI-5. 

H.  PROBLEMS  WITH  DIVETRACKER 

A  problem  with  the  DiveTracker  was  discovered  in  that  data  errors  would  show  up  in 
the  receiver  when  the  Hamming  transmitter/receiver  code  was  first  implemented.  The 
errors  were  consistent  in  that  they  occurred  at  the  same  place  in  the  string  of  received  data, 
and  they  displayed  the  same  characteristics.  The  problem  was  finally  discovered  to  be  lack 
of  flow  control  from  the  PC  to  the  DiveTracker,  causing  a  buffer  in  the  DiveTracker  to  fill 
up  and  overflow.  After  confirming  this  with  Desert  Star  Systems,  it  was  determined  that  the 
buffer  capacity  was  256  bytes.  To  correct  this,  handshaking  between  the  PC  and  the 
DiveTracker  needs  to  be  implemented.  Better  yet,  AMODEM  should  be  modified  to  send 
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an  X-OFF  when  the  buffer  is  more  than  3/4  full  and  send  an  X-ON  when  the  buffer  has  been 
emptied  to  1/2  capacity.  For  the  test  this  problem  was  corrected  simply  by  inserting  a  forced 
wait  routine  in  the  character  sending  process,  which  effectively  gave  DiveTracker  a  chance 
to  stay  ahead  of  the  data  flow.  However,  this  situation  shed  light  on  the  whole  concept  of 
serial  communications  and  flow  control.  It  is  recommended  that  more  RS-232  compliance 
be  built  into  AMODEM.  Request  To  Send  (RTS)  and  Clear  To  Send  (CTS)  functions  need 
to  be  built  into  Divetracker  code. 


Figure  VI-5:  Data  Communications  in  PVC  pipe. 

This  is  a  prime  example  of  the  requirement  to  re-think  every  aspect  of  re-designing  a 
protocol  foundation.  Even  the  simple  things  like  flow  control  between  communicating 
hosts  needs  to  be  looked  at  again  in  view  of  the  application  the  protocol  is  being  designed 
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for.  You  must  be  prepared  to  test  and  troubleshoot  at  all  layers  of  abstraction  in  order  to 
validate  correct  operation. 

A  problem  with  the  AUV  module  DiveTracker  was  also  experienced  in  that  for  some 
unknown  reason,  occasionally  the  flash  memory  which  stores  AMODEM  and  SMARTDIVE 
became  corrupted.  This  problem  would  reveal  itself  when  the  AUV  module  was  powered 
up  and  DfVETERM  executed.  The  memory  contents  had  extended  ASCII  characters  in  the 
menu  displayed  by  DIVETERM.  This  problem  was  resolved  simply  by  erasing  the  flash 
memory  and  reloading  the  programs.  This  problem  repeated  itself  several  times,  all  in  the 
AUV  DiveTracker  module. 

I.  MOSS  LANDING  TEST  PLAN 

In  order  to  validate  the  Hamming  encoder/decoder  system  in  an  actual  environment 
suitable  for  AUV  operations,  the  North  harbor  of  Moss  Landing  was  selected  for  a  test 
location.  Factors  influencing  this  decision  were  the  location’s  lack  of  boat  and  tourist 
traffic,  ease  of  access,  and  a  dock  which  eliminated  the  need  for  a  boat.  Figure  VI-6  shows 
a  gross  view  of  Moss  Landing  proper,  and  the  close-up  in  Figure  VI-7  shows  the  actu^ 
transducer  locations  for  the  tests.  Initial  tests  were  conducted  with  the  diver’s  station  and  a 
portable  notebook  computer  as  the  transmitter,  and  a  surface  station  connected  to  a  laptop 
computer  as  the  receiver.  In  all  tests,  the  receiver  was  located  at  the  finger  pier  Point  “A” 
in  Figure  Vl-7  and  transducer  depth  was  about  6  feet.  The  first  tests  were  conducted 
between  Point  “A”  and  a  point  on  the  same  finger  pier  about  20  feet  away  and  involved 
simple  string  transmissions  without  Hamming  encoding  to  test  the  system.  During  these 
tests,  the  maximum  speed  possible  was  determined  to  be  “3”,  corresponding  to  250  Baud. 
Tests  1-5  were  conducted  to  verify  the  correct  operation  of  the  system  and  are  presented  in 
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Table  VI-4.The  transmitter  set  was  then  moved  to  Point  “B”  and  tests  7-9  were  sent  using 


Figure  VI-6:  Moss  Landing  Harbor,  Moss  Landing,  California 
[NOS  92] 


81 


Figure  VI -7:  TVansducer  positions  for  Moss  Landing  test 
[NOS  92]. 
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Test 

# 

#of50 

byte 

strings 

1 

20 

2 

5 

3 

10 

4 

10 

5 

5 

6 

5 

7 

5 

8 

20 

9 

5 

10 

5 

11 

5 

12 

5 

13 

5 

14 

5 

15 

5 

16 

5 

17 

5 

1 

18 

5 

19 

5 

20 

5 

Powe 


From 


255 

1000 

255 

1000 

255 

1000 

255 

1000 

255 

1000 

255 

1000 

255 

2500 

255 

5000 

255 

5000 

255 

1000 

128 

1000 

064 

1000 

064 

1000 

064 

1000 

064 

1000 

064 

1000 

064 

1000 

064 

1000 

064 

1000 

048 

1000 

Remarks 

Test  File 
Name 

Uncoded,  no  errors 

l.tst 

Uncoded,  one  error 

2.tst 

Uncoded,  many 
errors 

3.tst 

Uhcoded,  no  errors 

4.tst 

Coded,  no  errors 

5H.tst 

Coded,  many  errors, 
data  unusable 

6H.tst 

Uncoded,  many 
errors,  data  unusable 

7.tst 

Uncoded,  many 
errors 

8.tst 

Uncoded,  one  error 

9.tst 

Uncoded,  no  errors 

lO.tst 

Uncoded,  less  power 

Il.tst 

Uncoded,  some 
errors 

12.tst 

Coded,  4  errors,  all 
corrected 

13H.tst 

Uncoded,  no  errors 

14.tst 

Dropped  synch, 
many  errors 

15H.tst 

Received  errors, 
fixed  some 

16H.tst  1 

Uncoded,  some 
errors 

n.tst 

No  errors 

18H.tst 

No  errors 

19H.tst 

No  errors 

20H.tst 
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Test 

# 

#of50 

byte 

strings 

Speed 

Power 

Level 

Pulse 

Length 

From 

To 

Remarks 

Test  File 
Name 

21 

5 

2 

024 

1000 

C 

A 

No  errors 

21H.tst 

22 

5 

2 

12 

1000 

C 

A 

Unreadable 

22H.tst 

23 

5 

2 

18 

1000 

C 

A 

Dropped  synch  in 

4th  string 

23H.tst 

Table  VI-4:  In-water  test  data. 

a  longer  pulse  length.  Specific  parameters  for  each  test  are  displayed  in  Table  VI-4,  Data 
received  was  badly  garbled.  Pulse  length  was  lengthened  again,  but  the  data  was  stUl 
garbled.  Finally,  transmission  speed  was  reduced  until  data  was  received  without  error  at 
Point  “A.”  As  communications  between  test  teams  was  done  verbally,  it  was  decided  to 
move  to  Point  “C,”  in  order  to  get  data  with  some  errors  in  the  transmitted  string  without 
dropping  synchronization  and  see  how  the  Hamming  code  would  repair  the  errors.  At  Point 
“C,”  power  levels  were  dropped  until  errors  were  seen,  in  test  number  13.  Additional  tests 
were  run,  but  the  results  did  not  change  as  power  continued  to  be  reduced.  Finally,  at  power 
level  12,  complete  loss  of  data  was  experienced.  Upon  raising  power  to  18,  no  errors  were 
seen.  Unfortunately,  2  tests  out  of  23  yielded  data  that  was  usable.  However,  these  two  tests 
are  significant  in  that  ERRORS  WERE  CORRECTED.  This  data  will  be  used  in  the  same 
table  as  was  the  simulation  data. 

J.  DATA  RESULTS 

Results  of  the  simulation  and  the  in-water  tests  are  displayed  below  in  Figure  VI-4 . 
Table  VI-2  is  the  results  from  the  PC-PC  simulation. 

1.  DISCUSSION 

Analysis  of  the  data  from  Tests  1 3  and  1 6  shows  that  in  test  1 3, 4  errors  were  received, 
4  errors  were  detected,  and  3  were  correctly  corrected.  The  one  that  was  incorrectly 
corrected  would  have  nonetheless  signalled  an  operator  that  this  message  would  probably 
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require  a  retransmission.  However,  3  retransmissions  werq  avoided.  In  Test  16,  9  errors 
were  seen  received,  6  were  correctly  corrected,  3  were  incorrectly  corrected,  and  3  were 
generated  in  the  output  string  in  error. 


Data 

Point 


Description 


Character  counts, 
percentages 


Original  string  sent  by  user: 


Total  bytes  for  Hamming  encoded 
characters 


DiveTracker  pulse-position 
coding  adds  synchronization  to 
two  bytes 


Noise  added  during  acoustic 
transmission,  propagation,  and 
reception 


DiveTracker  pulse-position 
coding  delivers  two  bytes,  with 


All  bits  eligible  for  error 


Probability  that  a  single  bit  is  in 


Errors  induced  (in  water  or 
simulation) 


Flags  marking  characters  with 
errors  detected 


Hamming  (decoded-only) 
uncorrected  characters 


Hamming  corrected  characters 


Undetected  /  unconected  errors 


%  received  characters  in  error 
prior  to  applying  correction 


%  characters  correct  and 
corrected 


2All25(i=  244/250= 

98.8%  97.6% 


Table  VI-5:  In-water  results  for  Test  #13  and  #16. 


It  is  probable  that  this  is  due  to  some  of  the  actual  Hamming  parity  bits  being  damaged 
and  the  correction  algorithm  making  a  best  guess  as  to  how  to  fix  it.  At  any  rate,  errors  were 
detected  and  the  operator  signalled.  In  this  test,  3  retransmissions  were  also  avoided. 

This  experiment  shows  how  interrelated  power,  speed,  pulse  length,  water  depth,  and 
numerous  other  factors  all  work  together  to  form  a  specific  set  of  parameters  for  each 
communications  channel.  It  is  significant  that  data  transfer  was  possible  after  REDUCING 
power  output  and  pulse  length.  Perhaps  reverberation,  multipath,  or  interference  from 
berthed  vessels  had  a  destmctive  effect  on  the  acoustic  communications.  Whatever  the 
cause,  it  presents  another  challenge:  to  devise  a  optimum  parameter  determination  program 
that  each  end  of  a  communications  channel  can  run  to  find  the  precise  combination  of 
parameters  for  a  particular  location  and  time.  One  possible  way  to  do  this  would  be  to 
synchronize  both  ends  of  the  link  by  system  clocks,  then  run  a  time-based  testing  program 
that  would  record  transmit  and  receive  results  based  on  an  actual  real-time  clock.  In  order 
to  determine  what  state  each  computer  was  in  during  each  test  phase,  it  would  only  require 
examination  of  the  data  log  with  the  clock  entry. 

The  bottom  line  of  this  section  is  that  although  not  a  great  deal  of  data  was  usable,  the 
idea  that  reliability  of  transmitted  data  can  be  improved  was  shown  successfully. 
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VII.  CONCLUSIONS  AND  RECOMMENDATIONS 

A.  CONCLUSIONS 

Although  many  different  acoustic  communications  devices  exist,  little  or  no 
compatibility  exists  among  them.  Research  efforts  in  acoustic  communications  have 
focused  on  increasing  bandwidth  at  low  bit-error  (BER)  rates  without  emphasizing  reliable 
message  delivery.  Examination  of  the  Internet  Protocol  (IP)  protocol  suite  shows  that 
IP/SW  is  a  possible  network  protocol  which  can  help  make  acoustic  telemetry  components 
interchangeable  and  efficiently  structured. 

The  goal  of  IP/SW  is  to  provide  direct  connectivity  between  underwater  acoustic 
devices  and  the  global  Internet.  Reliable  delivery  of  communications  packets  is  a  critical 
capability  missing  from  current  acoustic  telemetry  devices.  Using  example  Hamming 
error-detection/error-correction  codes,  simulation  and  in- water  testing  shows  how  EEC  can 
improve  message  reliability  while  reducing  prohibitively  expensive  retransmission 
requests. 

Any  level  of  correction  is  possible,  but  environmental  noise  be  characterized  and 
exploited  by  coding  algorithms.  For  example,  the  noise  created  by  a  powerboat  moving  at 
high  speed  nearby  creates  a  completely  different  type  of  noise  than  a  piledriver  or  snapping 
shrimp.  Specific  additional  conclusions  follow. 

1.  FEC,  not  ARQ 

Forward  error  correction  can  reduce  the  number  of  retransmissions  required  by  3  to  15 
percent,  based  on  experimental  results.  Although  these  figures  reflect  the  simulation  data 
instead  of  the  in-water  test  data,  it  is  believed  that  with  sufficient  tuning  of  the  many 
competing  parameters  in  the  acoustic  modems,  these  figures  can  be  realized  during  further 
testing. 


87 


2.  Testing  is  Paramount 

Valid  data  can  only  be  obtained  by  doing  actual  tests.  Difficulties  in  finding  a  location, 
communication  with  assistants,  sources  of  power,  weather,  and  accessibility  are  aU  reasons 
for  not  doing  actual  in-water  tests.  However,  as  can  be  seen  in  this  thesis,  simulations  do 
not  tell  the  whole  story.  There  was  no  way  to  duplicate  the  conditions  or  errors  received 
when  transmitting  in  real  water  during  the  simulation  previously  run.  Moreover,  actual 
testing  provides  insights  into  interrelated  parameters  and  conditions  which  open  more 
questions  for  further  study. 

3.  FEC  is  Easily  Implemented 

Although  these  tests  used  a  basic  Hamming  code,  there  are  other  possible  codes  that 
are  slightly  more  involved.  Appendix  E  lists  two  Reed-Solomon  encoder/decoders  which 
were  not  able  to  be  implemented  due  to  time  constraints.  Although  slower  than  hardware, 
software  is  quickly  prototyped  and  much  cheaper  to  experiment  with  than  is  hardware.  We 
expect  that  Hamming  codes  are  close  to  an  optimal  general  solution.  Extensive  testing  may 
show  other  codes  to  be  more  efficient  in  specific  acoustic  noise  environments. 

4.  Internet  Can  Be  Extended  Underwater 

By  transmitting  simple  text  messages,  it  can  be  seen  that  these  are,  in  fact,  small 
packets.  IP  packets  are  built  ft-om  many  small  packets  cemented  together.  Granted,  there 
are  many  levels  of  abstraction  that  are  not  being  addressed,  but  with  the  proper  protocols, 
especially  at  the  MAC  and  Data  Link  layers,  extension  of  the  Internet  to  underwater  entities 
is  only  a  matter  of  time. 

5.  Where  This  Is  Headed 

Standardization  is  the  key  to  acceptance  of  any  new  idea.  Just  as  the  wireless  and 
cellular  telephone  communities  are  striving  for  standards  so  communications  can  progress 
into  the  future,  so  must  the  underwater  acoustic  data  communications  community.  The 
problem  is  that  there  are  not  really  enough  users  to  pressure  the  groups  that  have  proprietary 
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systems  that  are  tailored  to  their  specific  applications  and  are  working  as  well  as  they  need 
them  to  work.  Actually,  this  process  is  not  only  necessary,  but  inevitable! 

B.  RECOMMENDATIONS  FOR  FUTURE  WORK 

1.  Moving  Layer  Functionality  Down  Towards  Hardware 

Let  the  appropriate  layer  do  the  appropriate  job.  Similar  but  not  necessarily  identical 
to  other  implementations  such  as  Ethernet.  In  particular,  parameters  will  be  far  different. 

2.  Different  Coding 

Other  coding  methods  are  available,  and  source  code  is  available  for  implementation 
and  experimentation.  Sources  for  two  Reed-Solomon  encoder/decoders  are  given  in  the 
reference  section.  Another  avenue  is  creation  of  new  coding  methods  to  maximize  some 
particular  aspect  of  FEC.  For  example,  in  addition  or  instead  of  a  block  error  correction  for 
bit  errors,  you  can  recover  whole  blocks  in  a  tunable  way  by  bitwise  exclusive  or  N  blocks 
to  produce  a  summary  block.  If  you  detect  losing  any  one  block,  you  can  X-OR  all  the 
others  with  the  summary/  checksum'  block  to  recover  the  missing  block.  Another  design, 
which  was  implemented  in  a  prototype  but  not  generalized  yet,  was  to  use  GNU  ecc  to 
encode  small  blocks  for  bit  errors  then  wrap  blocks  in  framing  (start  characters,  length, 
checksum)  and  X-OR  blocks  to  a  tunable  number  of  windowed  summary  blocks.  I.e.:  setup 
X  summary  blocks.  While  sending  blocks,  X-OR  each  block  into  the  X 
[current_block_number  (N)%  num_summary_registers]  summary  register.  You  then 
output  the  summary  blocks  every  so  often  and  start  over.  You  can  tune  how  often  to  send 
the  summary  blocks  and  how  many  there  are.  This  gives  you  failure  recovery  for  up  to  X 
blocks  in  a  row  (or  in  X  different  slots)  every  PERIOD  blocks.  The  Reed-Solomon  or 
similar  block  encoding  can  help  by  recovering  from  N  bit  flips  in  each  of  the  blocks, 
improving  the  chances  of  each  block  surviving.  With  those  parameters  you  should  be  able 
to  handle  a  pretty  high  level  of  noise  in  a  tunable  way. 
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The  Hamming  code  used  in  this  thesis  created  3  bytes  out  of  2.  However,  [V ukadin  9 1  ] 
describes  use  of  a  7,4  hamming  code  to  take  each  byte,  break  it  up  into  2  nibbles,  and 
encode  each  nibble  with  the  code.  Now,  each  byte  will  be  encoded  using  2  7-bit  hamming 
words,  making  each  byte  stand  alone  as  a  series  of  one  transmission  parameter  for  the 
Divetracker  routine  of  2  bytes,  then  2  more  bytes,  etc.  Preambles  for  synchronization  are 
still  needed. 

3.  Necessity  of  IETF  Standards 

It  cannot  be  stressed  strongly  enough  that  without  standardization,  compatibility 
among  acoustic  devices  will  never  be  realized.  An  open,  public  dialog  in  the  acoustic 
telemetry  community  that  includes  academics,  industry,  users  and  students  needs  to  be 
started  that  can  lead  to  a  standardization  process  for  IP/SW  using  the  guidelines  provided 
by  the  Internet  Engineering  Task  Force  (IETF)  [Stewart  94,  lAB  95]. 

4.  FEC  Filter  to  Include  Selectable  Encoding  Algorithms 

As  the  acoustic  channel  changes,  be  it  in  orientation  or  environment,  encoding  and 
decoding  methods  required  for  accurate  communications  will  change  as  well.  Some  form 
of  feedback  to  the  transmitter  will  be  required  to  allow  the  transmitter  to  modify  its 
encoding  algorithm  and  to  let  the  receiver  know  that  the  changes  were  made  so  that  the 
decoding  algorithm  can  be  changed  in  turn.  This  may  be  hard-coded  into  the  system,  or 
dynamic  so  changes  are  able  to  be  made  as  conditions  change. 

5.  Incorporation  Into  NPS  AUV  Architecture 

Work  has  already  begun  on  implementing  the  DiveTracker  system  into  the  NPS 
Phoenix  AUV  for  navigation  purposes  so  that  both  the  AUV  operating  system  and  the 
operating  personnel  know  vehicle  location  with  respect  to  a  baseline.  The  SMARTDIVE 
DiveTracker  operating  system  (DTOS)  is  already  programmed  to  handle  a  specialized 
message  communications  protocol  used  to  send  control  messages  to  and  from  the  AUV ,  but 
higher  level  protocols  have  yet  to  be  implemented  both  into  DTOS  and  into  the  strategic 
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levels  of  the  AUV  operating  system.  Incorporation  of  a  FEC  code  that  meets  the 
requirements  set  forth  in  Chapter  V  pertaining  to  compatibility  with  existing  protocols  is 
easily  done  with  a  protocol  that  is  still  very  plastic.  Enabling  the  AUV  to  receive 
higher-level  messages,  either  from  the  DiveTracker  surface  station,  another  ROV-mounted 
DiveTracker,  or  even  a  diver  in  the  water  would  be  one  step  closer  to  achieving  IP  over 
Seawater. 

6.  AOSN  and  Oceanographic  Research 

Without  reliability,  an  Autonomous  Ocean  Sampling  Network  will  fail.  Furthermore, 
any  AUV  transiting  through  the  area  will  be  at  risk  of  loss.  Reliability  is  needed  in  such  a 
network  and  can  be  obtained  through  incorporation  of  FEC  into  the  network 
communications. 

7.  Point  Sur  SOSUS  Array 

The  Nav^  Postgraduate  School  has  established  an  Ocean  Acoustic  Observatory  in  the 
Monterey  Bay  National  Marine  Sanctuary  for  the  purpose  of  undersea  research.  Located 
immediately  South  of  the  Point  Sur  Light-station,  Big  Sur,  California,  the  Point  Sur  Naval 
Facility  was  part  of  the  Navy's  underwater  monitoring  network  (1958-1 986)  to  acoustically 
track  ships  and  submarines  using  horizontal  arrays  of  sound  powered  hydrophones.  The 
school  is  preserving  the  array  Terminal  Equipment  compound,  and  one  horizontal 
hydrophone  array.  Though  some  of  the  information  on  the  facility  remains  classified,  the 
undersea  hydrophone  array  can  be  used  to  monitor  both  ship  and  mammal  traffic  passing 
through  the  Monterey  Bay  National  Marine  Sanctuary,  and  provide  unclassified  data 
(single  hydrophone  timeseries)  to  both  public  and  private  research  and  educational 
facilities.  In  addition,  this  asset  could,  if  properly  utilized,  provide  an  excellent  testbed  for 
communications  with  a  submerged  platform  or  even  a  surface  vessel  via  hydrophones.  It  is 
proposed  that  this  type  of  array  could  be  the  access  point  for  pelagic  AUVs  which  are  not 
restricted  to  near-shore  environments  to  communicate  mission  status  and  tasking.  For  more 
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information,  see  http:llwww.usMf.nps.navy.millptsur.html  or 
http:llwww.mbari.orglOcean_Engineeringl95e333.html. 

8.  Quantitatively  Determine  Signal  to  Noise  Ratio  (SNR) 

Noise  data  from  a  variety  of  underwater  environments  needs  to  be  collected  and 
recorded,  then  played  back  at  representative  signal  levels  in  a  test  tank  or  pool  while  various 
FEC  codes  are  tested  for  reliability.  Use  of  Reed-Solomon  codes  (such  as  the  code  in 
Appendix  E),  and  alternate  codes  might  be  tested  and  incorporated  into  the  NFS  AUV 
system. 

9.  Implementation  of  DiveTracker  in  the  WHOI  ALAN  Project 

The  Acoustic  LAN  described  in  [Catipovic  93]  [McMullen  94]  was  unable  to  meet 
expectations  because  of  battery  extinction  due  to  continues  retransmissions  of  messages 
which  were  never  received  by  the  intended  receiver.  This  caused  the  entire  project  to  be 
recovered  and  sent  back  to  Woods  Hole  Oceanographic  Institution.  Those  problems  were 
essentially  the  problem  statement  for  this  thesis.  An  excellent  follow-on  thesis  might  be  the 
installation  of  DiveTrackers  in  the  same  orientation  and  tasking  as  the  original  ALAN,  and 
by  incorporating  FEC,  determine  whether  it  can  be  accomplished. 

10.  Protocol  Analysis 

[Talavage  94]  presents  a  store-and-forward  protocol  that  could  easily  be  analyzed  and 
implemented  in  the  NPS  DiveTracker  system.  This  would  make  an  excellent  thesis  topic 
for  a  network  student. 

1 1.  Implementation  of  PPP 

Because  the  Point-to-Point  protocol’s  only  requirement  is  a  full-duplex  channel  (in 
order  to  use  HDLC),  it  makes  no  demands  on  the  modem  or  RS-232  interface  other  than 
Receive  and  Transmit.  This  makes  it  ideal  for  implementation  using  a  set  of  4  acoustic 
modems  to  provide  duplex  channels,  or  if  2  duplex-capable  modems  are  available  [Fischer 
93]  they  can  be  used  as  a  starting  point. 


92 


12.  Additional  Improvements  to  AMODEM.DC 

AMODEMDC's  software  configuration  program  needs  additional  integration  between 
speeds  3  and  4.  A  speed  of  3  seems  to  be  too  slow,  and  a  speed  of  4  is  too  fast.  At  best,  this 
might  be  a  sliding  control  that  is  user-configurable  from  speeds  of  very  slow  to  a  maximum 
of  around  4800  Baud.  In  addition,  as  was  mentioned  before,  AMODEMDC  would  benefit 
greatly  from  flow  control.  Implementation  of  flow  control  into  AMODEMDC  is  also  work 
which  would  provide  a  networking  or  software  engineering  student  well. 
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APPENDIX  A:  CODE  AND  SOURCES 


Compilation  of  this  code  was  done  at  the  command  line  using  Borland  C++  or  Turbo 
C.  The  file  PROMJTCJJB  was  put  into  theNLIB  directory,  and  the  file  PROMODEM. H 
was  put  into  the  MNCLUDE  directory  of  the  C  compiler.  Every  compilation  was  done  by 
invoking  the  Turbo  C  compiler  as  C:\>TCC  <FILENAME>  PROM_TC.LIB  or  the 
Borland  C++  compiler  as  C:\>BCC  <FILENAME>  PROM_TC.LIB  in  order  to  provide  the 
compiler  the  location  of  the  ProModem  library  file. 


1.  HAMMING  ENCODER  SIMULATION  (TRANSMITTER  SIDE) 

/*  HAMMSIMM.C  Hamming  Encoder /DecoderSimulat ion  by  Stephen  P.  Reimers  */ 

/*  Code  liberally  borrowed  from  TERMINAL. C  by  Adrian  J.  Michaud  */ 

/*  compiled  using  Borland  C++  at  command  line  */ 

tinclude  <string.h> 

#include  <stdio.h> 

#include  <conio.h> 

#include  <stdlib.h> 

#include  <math.h> 

#include  <time.h> 

#include  <dos.h> 

#include  'promodem. h' 
float  P_single_bi t_error; 
int  Bit_Error_Freq; 
int  total_€rrors_injected  =0; 

#define  DECODED_STR_LEN  52 
#define  ENCODED_STR_LEN  78 
FILE  *fp; 

void  hamming_encoder (char  input_string ( ] ,  char  encoded_string [ ] ) ; 
void  inject_error (char  encoded_string [ ] ,  char  Gncoded_error_string [ ] ) ; 
void  main (void); 

void  main (void) 

{ 

char  f ilename [ 20 ] ; 

char  main_input_string[DECODED_STR_LEN]  =  'The  purpose  of  computing  is  insight, 
not  numbers!!'; 

char  xmit_encoded_string[ENCODED„STR_LEN] ; 

char  xmit_encoded_error_string [ENCODED_STR_LEN] ; 

int  i,  count; 

int  repetitions; 

char  ch; 

AJMS  cbl; 

unsigned  int  irq=0,  base^address=0 ; 
char  com_jDort  [ 80 ]  ;  ^ 

char  baud_rate [ 80 ] ; 
long  baudRate=0; 

print f ( ^Enter  name  of  record  file:  " ) ; 
gets ( filename) ; 
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if  (  (  fp  =  fopen  {filename,  "w"))  ==  NULL) 

{ 

fprintf (stderr,  "Error  opening  file  %s.  ",  filename); 
exi t (1 ) ; 

} 

print f ( "Enter  comm  port  to  use:  "); 
gets (com_port) ; 

printf ( "Enter  baud  rate:  "); 
gets(baud_rate) ; 

printf ( "Enter  number  of  repetitions:  "); 
fprintf (fp, "\nEnter  number  of  repetitions:  ") ; 
scanf("%d",  ficrepetitions) ; 
fprintf (fp,  "%d",  repetitions); 

printf ("Bit  error  frequency  (8  or  16):  "); 
fprintf (fp,  "\nBit  error  frequency:  "); 
scanf  ("%d",  ScBi t_Error_Freq)  ; 
fprintf  (fp,  "%d*',  Bit_Error_Freq)  ; 

printf ( "Enter  the  probability  of  a  single  bit  error:  "); 
fprintf (fp,  "\nSingle  bit  error  probability:  "); 
scanf  ("%f  ",  ScP_single_bit_error)  ; 
fprintf (fp,  "%f\n",  P_single_bit_error) ; 

/*  initialize  arrays  with  all  zeros  */ 
for  (  i=0;  i  <  ENCODED_STR_LEN;  i++  ) 
xmit_encoded_string [i ]  =  0; 

while  (!irq  &&  ! base_address) 

{ 

/*  printf ("Enter  Com  port  [1  or  2]:  "); 
gets  (com_jport )  ;  *! 

if  (strstr (com_port ,  "1")) 

{ 

base_address  =  0x3f8; 
i rq  =  4 ; 

} 

else 

if  (strstr (com_port ,  "2")) 

{ 

base_address  =  0x2f8; 
i rq  =  3  ; 

) 

} 

#define  BUFFER_SIZE  4096  /*  Use  a  4K  IRQ  Buffer  */ 

SetupControlBlock  (£tcbl  ,  base_address  ,  irq  ,  BUFFER_SIZE)  ; 

if  {OpenCom{&cbl)  !=  SUCCESSFUL)  /*  Open  Com  Port 

{ 

printf  { \nCan '  t  Open  Com  Port!"); 
return; 

)  , 

while  (IbaudRate)  /*  Obtain  desired  Baud  Rate  */ 

{ 

/*  print f {" \nEnter  Baud  Rate  (300 , 2400, 9600 , 19200 , 38400 ,.  ^  ..  ) 
fprintf (fp,  "\nEnter  Baud  Rate: 
gets (baud_rate) ; 

fprintf (fp,  "%s",  baud_rate) ;  */ 
baudRate  =  atol (baud_rate) ; 

) 
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SetBaudRate (&cbl ,  baudRate) ;  /*  Sets  up  Baud  Rate  */ 

SetDataFormat  (ScCbl,  BITS_8  I NO_PARITY  I  ST0P_BITS_1 )  ;  /*  8-N-l  */ 

if  (SetFIFOMode(&cCbl)  ==  FIFO^ENABLED)  /*  Enable  16550  if  any  */ 

{ 

SetFIFOTriggerLevel (&cbl,  FIFO_16_TRIGGER) ;  /*  Turn  on  16  byte  RCVR  FIFO  */ 
printf ("\nUART  is  a  16550!  FIFO^s  Enabled. \n" ) ; 

} 

/*  else  printf ("\nUART  is  a  16540  or  8250. \n");  */ 

/*  if  (GetCTSRTSStatus{&cbl)  ==  ENABLED)  */  /*  Check  if  CTS/RTS  is  on  */ 

/*  printf ("\nCTS/RTS  Hardware  Handshaking  Enabled! \n" ) ; 
else 

printf {"\nCTS/RTS  Hardware  Handshaking  Disabled! ^n" ) ;  */ 

/*  printf ("\nLoad  ANSI. SYS  if  you  wish  to  display  ANSI.Xn"); 

printf (" \nPress  [ESC]  to  Exit  this  Terminal  Program. . \n" ) ;  */ 

/*  printf ("Input  a  string  up  to  %d  characters  long.  \n",  DECODED_STR_LEN) ; 
gets (main_input_string) ;  */ 

printf ("This  is  the  input  string:  %s  \n",  main_input_string  ); 
fprintf(fp,  "\nThe  input  string:  %s  \n" ,  main_input_string  ); 

hamming^encoder (main_input_string,  xmit_encoded_string  ); 

/*  printf ("This  is  the  xmit_encoded_string  (w/o  errors):  %s  \n", 
xmit_encoded_string  );  */ 

for  (count  =  0;  count  <  repetitions;  count++} 

{ 

printf ( "Cycle  number:  %d  \n",  count+1); 
fprintf(fp,  "Cycle  number:  %d",  count+1); 
for  (  i=0;  i  <  ENCODED_STR_LEN;  i++  ) 
xmit_encoded_error_string [ i ]  =  0; 


inject_error  (  xmit_encoded_string,  xmit_encoded_error_string) ; 

/*  printf ("This  is  the  xmit_encoded_string  (WITH  errors):  %s  \n", 
xmit_encoded_error_string) ;  *  I 

/*  printf ("Press  any  key  to  transmit  the  message.  \n");  */ 

/*  getch ( ) ;  */ 
sleep (3 ) ; 

for  (i  =  0;  i  <  ENCODED_STR_LEN;  i++) 

{ 

SendCharacter (&cbl ,  (unsigned  char) xm it _encodGd_erro r_st ring [ i ] ) ; 
i f  (kbhit ( ) ) 

{ 

ch  =  (char)  getch () ; 
if  (ch  ==  27)  break; 

} 

} 

)  /*  End  of  for  loop  to  go  repetition  times  */ 

CloseCom (&cbl ) ; 

DropDTR (&cbl ) ;  /*  Disable  Data  Terminal  Ready  */ 

print f ( "Total  number  of  errors  injected:  %d  \n",  total_errors_injected) ; 
fprintf(fp,  "\nTotal  errors  injected:  %d  \n",  total_errors_in jected ) ; 
f close ( fp) ; 


) 

void  hamming_encoder (char  input_string ( ] ,  char  encoded_string [ ] ) 
( 

unsigned  msg_charl,  msg_char2; 
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unsigned  mla,  m2a,  in3a,  in4a,  mBa,  in6a,  m7a,  m8a,  pla,  p2a,  p3a,  p4a 
unsigned  mlb,  m2b,  m3b,  in4b,  mSb,  iB6b,  mVb,  mSb,  plb,  p2b,  p3b,  p4b 

/*  long  int  coded_charl,  coded_char2;  */ 

7*  char  coded__c,  coded_d,  coded_e;  */ 
unsigned  coded_c,  coded_d,  coded_e; 
char  cde_string [4] ; 
int  i,  index,  n; 

/*  initialize  cde_string  to  all  zeros.  */ 
for  (  i=0;  i  <  4;  i++  ) 
cde_string[i]  =  0; 

n  =  strlen  (input__string)  ; 
if  { {n%2)  1=  0) 

{ 

strcat (input_string,  "  "); 
n  +  + ; 

} 


/*  printf  (''The  length  of  the  string  is  %d,  \n" ,  n)  ;  */ 

/*  parse  thru  current_string,  two  characters  at  a  time  */ 

for  (i=0;  i<  n;  i=i+2)  /*  positions  0  to  n~l  */ 

{ 

I*  msg_charl  is  one  character,  msg_char2  is  second  character  */ 
/*  now  loop  through  and  take  apart  msg_charl,  then  msg__char2  */ 
/*  These  are  the  same  8  bits,  but  different  types.  */ 
msg_charl  =  msg_char2  =  0; 
msg_charl  =  (int)  input_string[i] ; 
msg_char2  =  (int)  input_string( i+1 ] ; 

/*  printf ("Now  encoding  characterl  %d  \n",  msg_charl);  */ 


mla 

= 

m2a  =  m3a  =  m4a 

=  m5a  = 

m6a  =  m7a 

mla 

=: 

(msg_charl  &  1) 

»  0; 

m2a 

= 

(msg_charl  '&  2) 

»  1; 

m3a 

= 

(msg_charl  &  4) 

»  2; 

m4a 

= 

(msg_charl  &  8) 

»  3; 

m5a 

(msg_charl  &  16) 

»  4; 

m6a 

= 

(msg_charl  &  32) 

»  5; 

m7a 

=: 

{msg_charl  &  64) 

»  6 ; 

m8a 

= 

{msg_charl  &  128)  »  7; 

pla 

p2a  =  p3a  =  p4a 

=  0; 

pla 

= 

mla  m2a  m4a 

m5a 

m7a  ; 

p2a 

= 

mla  ^  m3a  m4a 

m6a  ^ 

m7a ; 

p3a 

= 

m2a  ^  m3a  ^  m4a 

^  m8a; 

p4a 

= 

mSa  m6a  ^  m7a 

^  m8a; 

f*  this  is  where  the  Hamming  code  gets  inserted  * ( 


mlb 

= 

m2b  =  m3b  =  m4b 

=  m5b  = 

m6b  =  m7b  =  m8b  = 

mlb 

= 

(nisg_char2  &  1) 

»  0.; 

m2b 

= 

(msg_char2  &  2) 

»  1; 

m3b 

=: 

(msg_char2  &  4) 

»  2; 

rri4b 

(msg_char2  &  8) 

»  3; 

m5b 

= 

(msg_char2  &  16) 

»  4  ; 

m6b 

= 

(msg_char2  &  32) 

5; 

m7b 

= 

(msg_char2  &  64) 

»  6; 

m8b 

{msg_char2  hi  128)  >>  7; 

plb 

p2b  =  p3b  =  p4b 

=  0; 

plb 

= 

mlb  m2b  m4b 

"  m5b 

m7b; 

p2b 

rr 

mlb  ^  m3b  ^  m4b 

m6b  '' 

m7b; 

p3b 

m2b  m3b  ^  m4b 

m8b; 
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p4b  =  m5b  ^  m6b  ^  m7b  m8b; 


/*  this  is  where  the  Hanuning  code  gets  inserted  */ 

/*  now  create  coded_c,  d,  and  e  of  type  char  */ 
coded_c  =  coded_d  =  coded_e  =  0;  ' 

coded_c  =  {  {mSa  <<  7)  +  (in7a  «  6}  +  (m6a  «  5)  +  (m5a  «  4)  + 

(p4a  «  3)  +  (m4a  «  2)  +  (m3a  <<  1)  +  m2a) ; 

/*  printf  ("coded_c:  %d%d%d%d%d%d%d%d  \n",  m8a,  ni7a,  in6a,  m5a,  p4a/  in4a, 
in3a,  m2a);  */ 

coded_d  =  ( {p3a  «  7)  +  (mla  «  6)  +  (p2a  «  5)  +  (pla  «  4)  + 

{in8b  «  3)  +  (in7b  «  2)  +  {m6b  «  1)  +  m5b)  ; 

/*  printf  ( "coded_d:  %d%d%d%d%d%d%d%d  \n",  p3a,  inla,  p2a,  pla,  mSb,  in7b, 
mSb,  iti5b)  ;  */ 

coded_e  =  (  {p4b  «  7)  +  {m4b  «  6)  +  {m3b  «  5)  +  (]n2b  «  4)  + 

{p3b  «  3)  +  (mlb  «  2)  +  (p2b  «  1)  +  plb) ; 

/*  printf  ("coded__e:  %d%d%d%d%d%d%d%d  \n",  p4b,  in4b,  m3b,  in2b,  p3b,  mlb, 
p2b,  plb);  */ 

/*  create  small  string  cde_string  out  of  the  coded_c,  d,  &  e  chars  */ 
for  (  index  =  0;  index  <  3;  index++)  /*  zero  array  */ 
cde_string[ index]  =  0; 
cde_string [0]  =  coded_c; 
cde_string [ 1 ]  =  coded_d; 
cde_string [2 ]  =  coded_e; 

/*  Lets  look  at  our  2  original  characters  which  is  now  a  3  character  string 
V 

/*  printf  ( ''This  is  our  3  character  encoded  string;  %x  %x  %x  \n", 
cde_string [0 ] ,  cde_string [ 1 ] ,  cde_string [2 ] ) ;  */ 

/*  now  we  build  the  encoded_string  out  of  the  cde_string  */ 

/*first  test  for  an  empty  string  */ 
if  (strlen (encoded_string)==0} 

{ 

/*  printf{''The  length  of  string  encoded_string  is  Zero.  \n");  */ 
strcpy (encoded_string,  cde_string) ; 

/*  printfl^The  encoded_string  now  looks  like  this:  %s  Xn", 
encoded_string) ;  * / 

} 

else 

/*  printf ( "going  to  the  else  clause,  strlen  >0.  \n");  */ 
strcat  (encoded_string,  cde_string) ; 

} 


}  /*  end  of  huge  for-loop  */ 

/*  printf("the  length  of  encoded_string  is  %d  \n",  strlen (encoded_string) ) ;  */ 
/*  the  string  is  now  encoded.  */ 

} 

/*  End  of  Hamming  Encoder  */  > 

/*********1r*****-^**t:*****-^**^**ic**ir**-^*******-k*ir**i.-„****-k*ic**ir****iriricic***iric**ir/ 

void  inject_error  (char  encoded_scring  [.  ]  ,  char  encoded_error_string  I  ]  ) 

int  i,  error_bit,  error_count=0 ; 
time_t  t; 

/*  initialize  array  */ 
for  (i  =  0;  i  V  ENCODED_STR_LEN  ;  i++) 
encoded_error_s t ring ( i ]  =  0; 
strcpy (  encoded_error_strinq,  encoded_string) ; 

srand { (unsigned)  time {&t ) ) ; 
if  (Bi t_Error_Freq  ==  8) 

t 

for  (i  =  0;  i  strlen (encoded_error_st ring) ;  i++) 
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/*  printf("i  is  now:  %d  \n",  i);  */ 

if  {(  randO  /  (pow{2.0;  15.0)  >  1))  < ■ P_single_bit_error ) 

{ 

/*  inject  error  in  a  single  random  bit  */ 

error_bit  =  rand()  %  8; 
switch  (error_bit) 

{ 

case  0: 

encoded_error_string [i ]  =  encoded_error_string [ i ]  1; 

break; 
case  1: 

encoded_error_string[i]  =  encoded_error_string [ i ]  ""  2; 
break; 
case  2 : 

encoded_error_string[i]  =  encoded_error_string [i ]  ^  4; 
break; 
case  3 : 

encoded_error_string[i]  =  encoded_error_string ( i ]  ""  8; 
break; 
case  4: 

encoded_error_string[i]  =  encoded_error_string [ i ]  ^  16; 
break ; 
case  5: 

encoded_error_string[i]  =  encoded_error_string [ i ]  ""  32; 
break; 
case  6 : 

encoded_error_string[i]  =  encoded_error_string [i ]  64; 

break; 
case  7 : 

encoded_error_string [ i ]  =  encoded_error_string [ i ]  128; 

break; 


} 

/*  printf ("Injected  error  into  character  %d  bit  %d  \n",  i+1, 
error_bit  +  1);  */ 

error_count++  ; 

} 

} 

} 

else  /■*  must  be  every  16  .bits,  instead  of  every  8.  This  eliminates  2  errors 
per  word.  */ 

{ 

for  (i  =  0;  i  <  strlen (encoded_error_string) ;  i  =  i+2  ) 

{ 

if  ((  randO  /  (pow(2.0,  15.0)  -  1))  <  P_single_bi t_error ) 

{ 

/*  inject  error  in  a  single  random  bit  */ 


error__bit  =.  randO  %  8; 
sv;itch  (error_bit) 

{ 

case  0: 

encoded_error_string [ i ]  =  encoded_error_string (i ]  ^  1; 
break; 
case  1 : 

encoded_Grror_string  [  i  i  =  encoded_error_string  [  i  ]  2; 

break; 
case  2 : 

encoded_error_scring [ i ]  =  encoded_error_string [ i ]  ^  4; 
break  ; 
case  3 : 

encoded_error_string  [  i  ]  =  encoded_error_string  [  i  ]  8; 

break ; 
case  4 : 

encoded_error_3tring  [  i  ]  =  encoded_error_string  [  i  ]  16; 

break ; 
case  5: 


100 


32; 


encoded_error_string[iJ  =  encoded_error_string [ i] 
break; 
case  6: 

encoded_error_string[i]  =  encoded_error_string [1 ]  ^  64; 
break; 
case  7 : 

encoded_error_string[i]  =  encoded_error_string [i ]  ^  128; 
break; 

/*  printf ("Injected  error  into  character  %d  bit  %d  \n",  i+1, 
error_bit  +  1);  */ 

error_count++; 

} 

} 

} 

printf ( "Errors  injected:  %d  \n",  error_count) ; 
fprintf.{fp,  "\nErrors  injected:  %d  \n",  error_count }  ; 
total_errors_injected  =  total_errors__injected  +  error_count; 


/********************  •k**icif**iricic*icir*****icici(ic*****-k**-kic*ir***-kic***********iticic-k-kic/ 

2.  HAMMING  DECODER  SIMULATION  (RECEIVER  SIDE) 

/*  RCVRSIMM.C  Receiver  Simulator  by  Stephen  P.  Reimers  */ 

/*  Serial  Code  liberally  borrowed  from  */ 

/*  TERMINAL. C  by  Adrian  J.  Michaud  */ 

#include  <string.h> 
tinclude  <stdio.h> 

#include  <conio.h> 

#include  <stdlib.h> 
tinclude  "promodem. h" 
tdefine  DECODED_STR_LEN  52 
tdefine  ENCODED_STR_LEN  78 
int  total_errors_corrected  =  0; 

void  hamming_decoder (char  encoded__string [ ] ,  char  error_string [ ] ,  char 
decoded_st ring [ ] ) ; 
void  clear_kb (void) ; 
void  main (void) ; 

FILE  *fp; 

void  main (void) 

{ 

char  f ilename f 20 ] ; 

char  rcvd_encoded_string [ENCODED_STR_LEN] ; 
char  rcvd_decoded_string [DECODED_STR_LEN] ; 
char  corrected_output_string [DECODED_STR_LEN] ; 

int  count  =  0; 
int  i,  a; 
int  repetitions; 
char  ch; 

AJMS  cbl; 

unsigned  int  irq-0,  base_address=0 ; 
char  com_port [80] ; 
char  baud_rate [ 80 j ; 
long  baudRate=0; 

print f ( "Enter  name  of  record  file:  "); 
gets (filename) ; 

if  (  (fp  =  fopen { filename,  "w"))  ==  NULL) 

( 

fprintf (stderr ,  "Error  openina  file  %s.",  filename); 
exi t ; 1 ; ; 
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} 

print f ("Enter  comm  port  to  use:  "); 

gets (com_port) ; 

printf ("Enter  baud  rate:  "}; 

fprintf(fp,  "\nEnter  baud  rate:  "); 

gets (baud_rate) ; 

fprintf  (fp,  "%s"  baud_rate) ; 

printf ("Enter  number  of  repetitions:  "); 

fprintf (fp, "\nEnter  number  of  repetitions:  "); 

scanf ("%d" ,  ^repetitions) ; 

fprintf (fp,  "%d"/  repetitions); 

for  (count  =  0;  count  <  repetitions;  count++) 

{ 

printf ("Cycle  number:  %d  \n",  count+1); 
fprintf (fp;  "\nCycle  number:  %d  \n",  count+1); 

/*  initialize  variables  */ 
for  (  i  =  0;  i  <  ‘ENCODED_STR_LEN;  i++  ) 
rcvd_encoded_string [i ]  =  0; 

for  (  i=0;  i  <  DECODED_STR„LEN;  i++  ) 

{ 

rcvd_decoded_string [i ]  =0; 
corrected_output_string [i ]  =  0; 

} 

while  (!irq  &&  ! base_address) 

{ 

if  (strstr (com_port ,  "1")) 

{ 

base_address  =  0x3f8; 
i rq  =  4 ; 

} 

else 

if  (strstr (com_port,  "2")) 

{  ■  • 

base_address  =  0x2f8; 

i  rq  =  3  ; 

} 

} 

#define  BUFFER^SIZE  4096  /*  Use  a  4K  IRQ  Buffer  */ 

SetupControlBlock (&cbl  ,  base_address  ,  irq  ,  .  BUFFER_SIZE) ; 

if  (OpenCom(&cbl)  i=  SUCCESSFUL)  /*  Open  Com  Port  */ 

{ 

printf ("XnCan't  Open  Com  Port!"); 
return; 

} 

while  (IbaudRate)  /*  Obtain  desired  Baud  Rate  */ 

{ 

baudRate  =  atol (baud_rate } ; 

} 

SetBaudRate (&cbl ,  baudRate);  /*  Sets  up  Baud  Rate  */ 

SetDataFormat (&cbl,  BITS_8 i NC_PARITY i STOP_BITS_l ) ;  /*  8-N-l 

*  / 

if  ISecFIFOMode  (Sicbl )  ==  FIFO_ENABLED)  /’  Enable  16550  if  any  */ 

1 

SetFIFOTriggerLevel  (S.cbl,  FIFO_16_TRIGGER)  ;  /*  Turn  on  16  byte  RCVR  FIFO 

*/ 

print.f  ("XnUART  is  a  16550!  FIFO's  Enabled . \n' )  ; 

! 
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/*  else  printf ("\nUART  is  a  16540  or  8250. \n");  */ 

if  (GetCTSRTSStatus  (&cbl)  ==  ENABLED)  Check  if  CTS/RTS  is  on  */ 

printf ("CTS/RTS  Hardware  Handshaking  Enabled! \n" ) ; 
else 

print f { "\nCTS/RTS  Hardware  Handshaking  Disabled! \n" ) ; 

/*  printf {"\nLoad  ANSI. SYS  if  you  wish  to  display  ANSI.Xn"); 
printf {"\nPress  [ESC]  to  Exit  this  Terminal  Program. . \n" ) ;  */ 

for  (  i=0;i  <  ENCODED_STR_LEN;  i++  )  /*  Loop  to  fill  string  */ 

{ 

if  (kbhit ( ) ) 

{ 

ch  =  (char) getch ( ) ; 
if  (ch  ==:  27) 
return; 

} 

while  (CheckQueue(&cbl) !=CHARACTERS_WAITING)  /*  Check  IRQ  buffer  for 
chars  */ 


rcvd_encoded_string[i]  =  GetCharacter(&cbl); 
printf (".') ; 

/*  printf ( "exited  while  loop!  \n");  */ 

} 

hamming_de coder (rcvd_encoded_string,  rcvd_decoded_string, 
correc ted_output_string) ; 

printf ("The  received  decoded  string:  %s  \n"/  rcvd_decoded_string  ); 
fprintf(fp,  "The  received  decoded  string:  %s",  rcvd_decoded_string  ); 

printf ("The  corrected  decoded  string:  %s  \n",  corrected__output^string  ); 
f printf ( fp, " \nThe  corrected  decoded  string:  %s  \n",  corrected_output_string 


CloseCom{&cbl); 

DropDTR(&cbl) ;  /*  Disable  Data  Terminal  Ready  */ 

/*  printf ("we've  reached  CloseCom  and  DropDTR.  \n");  */ 

}  /*  end  big  for-loop  f 

printf ("Total  errors  corrected:  %d  \n",  total_errors_corrected) ; 
fprintf(fp,  "\nTotal  errors  corrected:  %d  \n" ,  total_errors_corrected) ; 
f close ( fp) ; 

printf ("just  before  final  brace,  \n"}; 

)  /*  End  of  Main  */ 

/^Hamming  12/8  Decoder  */ 

void  hamming_decoder (char  encoded_string ( ] ,  char  error_string [ ] ,  char 
decoded_string [ ] ) 

{  ■  ' 
unsigned  msg_charl,  msg_char2; 

unsigned  mla,  m2a,  m3a,  m4a,  mSa,  m6a,  m7a,  m8a,  pla,  p2a,  p3a,  p4a; 
unsigned  mlb,  m2b,  m3b,  m4b,  m5b,  m6b,  m7b,  mSb,  plb,  p2b,  p3b,  p4b; 
unsigned  syndromel,  syndrome2 ,  new_syndromel ,  new_syndrome2 ; 

unsigned  new _ pi  a  =  0,  new  >  d2 a  =  0,  new_p3a  =  0,  new__p4a  =  0; 

unsigned  new_plb  =  0,^  new_p2b  =  0,  new_p3b  =  0,  new_p4b  =  o! 

unsigned  coded_c,  coded_d,  coded^e; 

char  a_string[2],  b_string(2]; 

unsigned  error_loca tionl ,  error_locat ion2 ; 

int  i,  b,  n,  error__count  =  0; 

int  index  =  0; 
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/*  now  get  the  encoded_string,  and  start  decoding  it  */ 

/*  printf("the  encoded_string :  %s  \n'',  encoded_string) ;  */ 

h  =  strlen (encoded_string) ; 

/*  printf ( "length  of  encoded_string  is  %d  \n"/  n) ;  */ 
if  ( (n%3)  !=  0) 

fprintf{fp,  "\nWARNING:  encoded  string  is  not  evenly  divisible  by  3!  \n") 
printf ("WARNING:  encoded  string  is  not  evenly  divisible  by  3!  \n"); 
if  ( (n%3)  ==  1) 

{ 

strcat{  encoded_string,  "  ");  /*append  2  spaces*/ 

n  =  n+2; 

} 

else  /*n%3  must  equal  2,  so  we  only  need  one  space  */ 

{ 

strcat(  encoded_string,  "  "); 
n++; 

} 

}/*end  of  if  clause  */ 

/*  parse  thru  output_string,  three  characters  at  a  time  */ 

for  (i  =  0;  i  <  n;  i  =  i+3)  /*  positions  0  to  n-1  */ 

{ 

/*  initialize  both  strings  to  all  zeros.  */ 
for  (  b  =  0;  b  <  2;  b++  ) 
a_string[bl  =  0; 

for  (  b  =  0;  b  <  2;  b++  ) 
b_string[b]  =  0; 

/*  printf ("this  is  the  nulled-out  a_string:  %s  \n",  a_string) ; 
printf ("this  is  the  nulled-out  b__string:  %s  \n",  b_string) ;  */ 

coded_c  =  (int)  encoded_string [i] ; 
coded_d  =  (int)  encoded_string [ i+1 ] ; 
coded_e  =  (int)  encoded_string [ i+2 ] ; 

/*  now  we  have  to  get  12  bits  back  out  of  the  3  chars,  which  are  the 
original  message  bits  plus  the  parity  bits.  */ 

mla  =  m2a  =  m3a  =  m4a  =  m5a  =  m6a  =  m7a  =  m8a  =  0; 

pla  =  p2a  =  p3a  =  p4a  =  plb  =  p2b  =  p3b  =  p4b  =  0; 

mlb  =  m2b  =  m3b  =  m4b  =  m5b  =  m6b  =  mVb  =  m8b  =  0; 


m8a 

= 

(coded_c 

& 

128)  » 

m7a 

= 

( coded__c 

& 

64) 

»  6 

m6a 

= 

(coded_c 

& 

32) 

»  5 

m5a 

(coded_c 

& 

16) 

»  4 

p4a 

= 

(coded__c 

& 

8) 

»  3; 

m4a 

(coded_c 

& 

4} 

»  2; 

m3a 

= 

( coded_c 

& 

2) 

»  1; 

m2a 

= 

(coded_c 

& 

1) 

»  0; 

p3a 

(coded_d 

& 

128 

)  » 

mla 

= 

(coded_d 

& 

64) 

»  6 

p2a 

= 

(coded_d 

& 

32) 

»  5 

pla 

= 

( coded_d 

Sc 

16) 

»  4 

m8b 

(coded_d 

Sc 

8) 

»  3; 

m7b 

( coded_d 

& 

4) 

»  2; 

m6b 

( coded_d 

Sc 

2) 

»  1 ; 

mSb 

= 

(coded_d 

Sc 

1) 

»  0; 

p4b 

= 

(coded_e 

Sc 

128 

)  » 

m4b 

{ coded_e 

Sc 

64  ) 

»  6 

m3b 

( codGd_e 

Sc 

32) 

»  5 

m2b 

= 

( coded_e 

Sc 

16) 

•»  4 

p3b 

( coded_e 

Sc 

8) 

>->  3; 

mib 

= 

( coded_e 

Sc 

4) 

»  2; 
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p2b  =  (coded_e  &  2)  »  1; 
plb  =  {coded_e  &  1)  »  0; 


msg_charl  =  insg_char2  =  0; 

msg_charl  =  (  (mSa  «  7)  +  (m7a  «  6)  +  (in6a  «  5)  +  (inSa  «  4)  + 

(m4a  «  3)  +  (in3a  «  2)  +  {ni2a  «  1)  +  mla); 

msg_char2  =  (  (m8b  «  7)  +  {m7b  «  6)  +  (ro6b  «  5)  +  {in5b  «  4)  + 

(in4b  «  3)  +  (m3b  «  2)  +  (m2b  «  1)  +  mlb)  ; 

/*  print f ("The  two  characters  decoded  are:  %c,  %c .  \n",  msg_charl, 
msg_char2);  */ 

/*  Create  the  string  of  UNCORRECTED  incoming  characters.  */ 

error_string[ index]  =  msg_charl; 
error_string  [  index+1  ]  =  msg__char2  ; 
index  =  {index  +2 )  ; 

/*create  the  syndrome  word  for  the  characters  received  */ 
syndromel  =  syndrome2  =  0; 

syndromel  =  (  (p4a  «  3)  +  (p3a  «  2)  +  (p2a  «  1)  +  pla); 

/*  printf("This  is  received  syndromel:  %x  \n",  syndromel);  */ 

syndrome2  =  ( (p4b  «  3)  +  (p3b  «  2)  +  (p2b  «  1)  +  plb) ; 

/*  printf("This  is  received  syndrome2 :  %x  \n",  syndrome2 ) ;  */ 

/*  recompute  the  parity  bits  from  the  received  characters  */ 

mla  =  m2a  =  m3a  =  m4a  =  m5a  =  m6a  =  m7a  =  m8a  =  0; 
new^pla  =  new_p2a  =  .new_p3a  =  new_p4a  =  0; 
new_j)lb  =  new_p2b  =  new_p3b  =  new_p4b  =  0; 
mlb  =  m2b  =  m3b  =  m4b  =  m5b  =  m6b  =  m7b  =  m8b  =  0; 

mla  =  (msg_charl  &  1)  »  0; 
m2a  =  (msg_charl  Sc  2]  »  1; 
m3a  =  (msg_charl  &  4)  »  2; 
m4a  =  (msg_charl  &  8}  »  3; 
mSa  =  (msg_charl  &  16)  »  4  ; 
m6a  =  (msg_charl  &  32)  »  5; 
m7a  =  (msg_charl  &  64)  »  6; 
m8a  =  (msg^charl  &  128)  »  7; 

new_pla  =  mla  ^  m2a  m4a  ^  m5a  m7a; 
new_p2a  =  mla  ^  m3a  ""  m4a  m6a  ^  m7a; 
new_p3a  =  m2a  m3a  m4a  ^  m8a; 
new_p4a  =  m5a  ^  m6a  ^  m7a  m8a; 

mlb  =  (msg_char2  &•!)  »  0; 
m2b  =  (msg_char2  &  2)  »  1; 
m3b  =  (msg_char2  &  4)  »  2; 
m4b  =  (msg_char2  &  8)  »  3; 
m5b  =  {msg_char2  &  16)  »  4; 
m6b  =  (msg_char2  &  32)  »  5; 
m7b  =  (msg_char2  &  64)  »  6; 
m8b  =  (msg_char2  &  128)  >>  7; 

new_plb  =  mlb  m2b  m4b  m5b  m7b; 
new_p2b  =  mlb  ^  m3b  m4b  ^  m6b  "  m7b; 
new_p3b  =  m2b  m3b  m4b  "  m8b; 
new_p4b  =  m5b  ^  m6b  "  m7b  "  m8b; 


new_syndromel  =  new_syndrome2  =  0; 

new_syndromel  =  { (new_p4a  «  3)  +  (new_p3a  «  2)  +  (new _p2a  1)  + 

new_j)la)  ; 

/*  print f ("This  is  new_syndromel :  %x  \n",  new_syndromel ) ;  */ 
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new_syndronie2  =  (  (new_p4b  «  3)  +  {new__p3b  «  2)  +  (new_jp2b  «  1)  + 
new_plb)  ; 

/*  printf("This  is  new_syndrome2 :  %x  \n",  new_syndrome2 ) ;  */ 

/*now  check  to  see  if  the  syndrome  words  are  the  same.  If  not,  perform 
bit-flipping  on  bit  in  error.  */ 

if  ( {new_syndromel  syndromel)  i=  0)  ■ 

{ 

error_locationl  =  (  {  (new_p4a  p4a)  <<  3)  +  (  {new_p3a  p3a}  «  2)  + 
( (new_p2a  ^  p2a)  «  1)  +  (new_pla  ^  pla)); 

/*  printf {"Error  at  location  %d.  \n",  error_locationl ) ;  */ 

error_count++ ; 

switch  (error_locationl ) 

{ 

.  case  1: 

{ 

pla  =  (pla  ^  1)  ; 
break; 

)  i 

case  2 : 

{ 

p2a  =  (p2a  1)  ; 
break ; 

}  ' 

case  3 : 

{ 

mla  =  (mla  ^  1) ; 
break; 

} 

case  4 : 

{ 

p3a  =  {p3a  ^  1 ) ; 
break; 

} 

case  5: 

{ 

m2  a  =  ( m2  a  ^  1 ) ; 
break; 

} 

case  6: 

{ 

m3a  =  (m3a  ^  1) ; 
break; 

} 

case  7 : 

{ 

m4a  =  (m4a  ^  1) ; 
break; 

) 

case  8: 

{ 

p4a  =  (p4a  1)  ; 

break ; 

} 

case  9; 

{ 

mSa  =  (m5a  1 )  ; 

break ; 

} 

case  10: 

{ 

m6a  =  (m6a  1 )  ; 

break ; 

} 

case  11  : 

{ 
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mVa  =  {m7a  1 )  ; 
break; 

} 

case  12 : 

{ 

m8a  =  {m8a  '^1); 
break;- 

} 

default: 

{ 

printf ( "something  is  going  wrong  in  case  for  syndromel .  \n" ) ; 

} 

}  /*  end  of  switch  statement.  */ 
msg_charl  =  0; 

msg_charl  =  ( (m8a  «  7)  +  (m7a  «  6)  +  (m6a  «  5)  +  {m5a  «  4)  + 
(m4a  «  3)  +  {m3a  «  2)  +  (m2a  «  1)  +  mla); 

/*  printf ("corrected  character  is:  %c  \n",  msg_charl);  */ 

} 

/*  printf ("we  made  it  to  the  end  of  the  if  block.  \n");  */ 


b_string{0]  =  msg_charl; 
if  (strlen (decoded_string)  ==  0) 

{ 

strcpy (decoded_string,  b_string) ; 

} 

else 

{ 

strcat  (decoded__string,  b_string)  ; 

} 


if  ( {new_syndrome2  ^  syndrome2)  !=  0) 

{ 

error_location2  =  {  ( (new_p4b  p4b)  «  3)  +  (  (new_p3b  ^  p3b)  «  2)  + 
(  (new_p2b  p2b)  «  1)  +  (new_plb  ^  plb)  )  ; 

/*  printf ("Error  at  location  %d.  \n",  error_location2 ) ;  */ 
error_count++; 

switch  (error_location2 ) 

{ 

case  1: 

{ 

plb  =  (plb  ^  1} ; 
break; 

) 

case  2 : 

.{ 

p2b  =  (p2b  ""  1)  ; 
break; 

} 

case  3 : 

{ 

mlb  =  (mlb  ^  1 } ; 
break ; 

) 

case  4 : 

{ 

p3b  =  (p3b  ""  1  )  ; 
break ; 

} 

case  5: 

{ 

m2b  =  (m2b  1 )  ; 
break ; 

}. 

case  6  : 
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{ 

iR3b  =  (in3b  1)  ; 

break; 

} 

case  7 : 

{ 

in4b  =  •  (in4b  ^  1)  ; 
break; 

} 

case  8: 

{ 

p4b  =  {p4b  1)  ; 

break; 

} 

case  9: 

{ 

m5b  =  {mSb  "  1) ; 
break; 

} 

case  10: 

{ 

m6b  =  {m6b  ^  1) ; 
break; 

} 

case  11: 

{ 

m7b  =  (in7b  ^  1)  ; 
break; 

} 

case  12 : 

{ 

mSb  =  {mSb  .1)  ; 
break; 

} 

default : 

{ 

printf ( 'something  is  going  wrong  in  case  for  syndrome2 .  \n') 

} 

}  /■*  end  switch  block  */ 

n^sg_char2  =  (  (m8b  «  7)  +  (m7b  «  6)  +  (m6b  «  5)  +  {m5b  «  4)  + 
(m4b  «  3)  +  (m3b  «  2)  +  {m2b  «  1)  +  mlb) ; 

/*  printf ('corrected  character  is:  %c  \n" ,  msg_char2) ;  */ 

} 


a_string[0]  =  msg_char2;  ’  • 

if  (strlen (decoded_strinq)  ==  0) 

{ 

strcpy (decoded_string ,  a_string) ; 

} 

else 

{ 

strcat (decoded_string,  a_string) ; 

} 

} 

print f ( "Error  count  for  string:  \n",  error_count); 

fprintf(fp,  "Error  count:  %d\n",  erro recount } ; 
total_errors_corrected  =  totai_errors_corrected  +  error_count; 

}  /*  End  function.  */ 


3.  UNCODED  ASCII  STRING  DIVETRACKER  TRANSMITTER 


/*  TRAN.C  Transmiccer  Simulator  by  Stephen  P.  Reimers  */ 
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/*  Serial  Code  liberally  borrowed  from  */ 

/*  TERMINAL, C  by  Adrian  J.  Michaud  */ 

/*  Compiled  using  Borland  C++  at  command  line  */ 

#include  <string.h> 

#include  <stdio.h> 

#include  <conio.h> 

#include  <stdlib.h> 

#include  <dos.h> 

# include  "promodem. h" 
tdefine  DECODED_STR_LEN  52 

FILE  *fp; 

void  main ( ) 

{ 

char  filename [20] ; 

char  main_input_string [DECODED_STR_LEN]  =  "The  purpose  of  computing  is  insight, 
not  numbers ! ! " ; 
int  i,  count; 
int  repetitions; 
char  ch; 

AOMS  cbl; 

unsigned  int  irq=0,  base_address=0 ; 
char  com_port[80]  =  "1"; 
char  baud_rate [ 80 ]  =  "4800"; 
long  baudRate=0; 
int  delayl,  delay2; 

printf ( "Enter  name  of  record  file:  "); 
gets  (  filename  ) ; 

if  (  (  fp  =  fopen  (filename,  "w"))  ==  NULL) 

{ 

fprintf (stderr,  "Error  opening  file  %s.  ",  filename); 
exi t { 1 ) ; 

} 

/*  printf ( "Enter  comm  port  to  use:  "); 
gets  (com__port)  ; 

printf ("Enter  baud  rate:  "); 
gets (baud_rate) ;  */ 

printf ( "Enter  number  of  repetitions:  "); 
fprintf (fp, "\nEnter  number  of  repetitions:  "); 
scanf("%d",  &repetitions) ; 
fprintf (fp,  "%d",  repetitions); 

while  (!irq  &&  !base_address) 

{ 

if  (strstr { com_port ,  "1")) 

{ 

base_address  =  0x3 f 8; 
irq  =  4; 

} 

else 

if  (strstr (com_port ,  "2")) 

{ 

base_address  =  0x2f8; 
irq  =  3; 

) 

} 


#define  BUFFER_SIZE  4096  /*  Use  a  4K  IRQ  Buffer  */ 

SetupControlBlock  (Sccbl  ,  base_address  ,  irq  ,  BUFFER_SIZE)  ; 
if  (OpenCom (&cbl)  !=  SUCCESSFUL)  /*  Open  Com  Port  */ 

{ 

printf ( "\nCan' t  Open  Com  Port!"]; 
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return; 


} 

while  (IbaudRate)  /*  Obtain  desired  Baud  Rate  */ 

’  { 

baudRate  =  atol (baud_rate) ; 

) 

SetBaudRate  (ScCbl,  baudRate);  /*  Sets  up  Baud  Rate  */ 

SetDataFonnat (&cbl,  BITS_8 INO^PARITY I ST0P_BITS_1) ;  /*  S-N-l  */ 

if  (SetFIFOMode(Sccbl)  ==  FIFO^ENABLED)  /*  Enable  16550  if  any  */ 

{ 

SetFIFOTriggerLevel (&cbl,  FIFO_16_TRIGGER} ;  /*  Turn  on  16  byte  RCVR  FIFO  */ 
printf ("\nUART  is  a  16550!  FIFO's  Enabled . \n" ) ; 

} 

else  printf {"\nUART  is  a  16540  or  8250. \n"); 

if*  (GetCTSRTSStatus- (&cbl)  ==  ENABLED)  /*  Check  if  CTS/RTS  is  on  */ 
printf ("XnCTS /RTS  Hardware  Handshaking  Enabled! \n" ) ; 
else 

printf ( "\nCTS /RTS  Hardware  Handshaking  Disabled! \n"); 


printf ("XnPress  [ESC]  to  Exit  this  Terminal  Program .. \n" ) ; 

print f { "This  is  the  input  string:  %s  \n",  main„input_string  ); 
fprintf(fp,  "\nThe  input  string:  %s  \n" ,  main_input_string  ); 

for  {count  =  0;  count  <  repetitions;  count++) 

{ 

printf ( "Cycle  number:  %d  \n",  count+1); 
fprintf(fp,  "Cycle  number:  %d\n",  count+1); 
sleep (1 ) ; 

for  (i  =  0;  i  <  DECODED_STR_LEN;  i=i+2) 

( 

SendCharacter (&cbl,  (unsigned  char)main__input_string [i ] ) ; 
SendCharacter (&cbl ,  (unsigned  char)main_input_string[i+l] ) ; 
for  (delayl=0;  delayl  <  1500;  delayl++) 

( 

for  (delay2=0;  delay2  <  500;  delay2++) 


if (kbhit ( ) ) 

{ 

ch  =  (char)  getch ( ) ; 
i f  (ch  ==  27 )  exit ( 1 ) ; 

} 

) 

}  /*  End  of  for  loop  to  go  repetition  times  */ 
CloseCom (&cbl ) ; 

DropDTR (&cbl } ;  /*  Disable  Data  Terminal  Ready  */ 

f close ( fp) ; 
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4.  UNCODED  ASCII  STRING  DIVETRACKER  RECEIVER 

/*  RCVR.C  by  Stephen  P.  Reimers  */ 

/*  Uses  PROMODEM  SERIAL  LIBRRARY  by  Adrian  J.  Michaud  */ 

#include  <string.h> 

#include  <stdio.h> 

#include  <conio.h> 

#include  <stdlib.h> 

# include  "promodem. h" 

#define  DECODED_STR_LEN  52 


void  clear_kb (void) ; 
void  main (void) ; 

FILE  *fp; 

void  main (void) 

{ 

char  filename [20] ; 

char  rcvd_string[DECODED_STR_LEN] ; 

int  count  =  0; 
int  i,  a; 
int  repetitions; 
char  ch; 

AJMS  cbl; 

unsigned  int  irq=0,  base_address=0 ; 
char  com_port[80]  =  "1"; 
char  baud_rate[80]  =  *4800"; 
long  baudRate=0; 

printf ( "Enter  name  of  record  file:  *); 
gets (filename) ; 

if  (  (fp  =  fopen( filename,  *w* ) )  ==  NULL) 

{ 

fprintf (stderr,  "Error  opening  file  %s.",  filename); 
exi t ( 1 ) ; 

} 

/*  printf ("Enter  comm  port  to  use:  "); 
gets (com_port) ; 
printf ( "Enter  baud  rate:  "); 
fprintf (fp,  "\nEnter  baud  rate:  "); 
gets(baud_rate); 

fprintf (fp,  "%s",  baud_rate);  */ 
printf ( "Enter  number  of  repetitions:  "); 
fprintf (fp, "\nEnter  number  of  repetitions:  "); 
scanf ("%d",  &repetitions) ; 
fprintf  (fp,  •-%d",  repetitions); 

for  (count  =  0;  count  <  repetitions;  count++) 

{ 

printf ( "Cycle  number:  %d  \n",  count+1); 
fprintf  (fp,  "\nCycle  number:  %d  \n" ,  count  +  1); 

/*  initialize  variables  */ 
for  (  i=0;  i  <  DECODED_STR_LEN;  i++  ) 
rcvd_strinq ( i ]  =  0; 
while  (!irq  &&  ! base_address ) 

( 

if  (strstr (com_port ,  "1")^ 

{ 

base_address  =  0x3 f 8; 
i rq  =  4  ; 

} 

else 
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if  (strstr {com_port ,  "2")) 

{ 

base_address  =  0x2f8; 

irq  =  3; 

} 

} 

#define  BUFFER_SIZE  4096  /*  Use  a  4K  IRQ  Buffer  */ 

SetupControlBlock  {Sccbl  ,  base_address  /  irq  ,  BUFFER_SIZE)  ; 

if  (OpenCom(&cbl)  !=  SUCCESSFUL)  /*  Open  Com  Port  */ 

{ 

printf { "\nCan' t  Open  Com  Port!"}; 
return; 

} 

while  (IbaudRate)  /*  Obtain  desired  Baud  Rate  */ 

{ 

baudRate  =  atol (baud_rate) ; 

} 

SetBaudRate (&cbl,  baudRate);  /*  Sets  up  Baud  Rate  */ 

SetDataFormat (&cbl.  BITS_8 INO_PARITYI STOP_BITS_l) ;  /*  8-N-l  */ 

if  (SetFIFOMode{&cbl)  ==  FIFO_ENABLED)  /*  Enable  16550  if  any  */ 

{ 

SetFIFOTriggerLevel  (ScCbl,  FIFO_16_TRIGGER)  ;  /*  Turn  on  16  byte  RCVR  FIFO 
V 

printf ( "\nUART  is  a  16550!  FIFO's  Enabled . \n" ) ; 

} 

/*  else  printf ( "\nUART  is  a  16540  or  8250. \n"); 

if  (GetCTSRTSStatus  (ScCbl)  ==  ENABLED)  /*  Check  if  CTS/RTS  is  on  */ 
print f { "CTS/RTS  Hardware  Handshaking  Enabled ! \n" ) ; 
else 

printf ( "\nCTS/RTS  Hardware  Handshaking  Disabled! \n" ) ; 

/*  printf (" \nLoad  ANSI. SYS  if  you  wish  to  display  ANSI.\n"); 
printf (" \nPress  [ESC]  to  Exit  this  Terminal  Program. . \n" ) ;  */ 

for  (  i=0;i  <  DECODED_STR_LEN ;  i++  )  /*  Loop  to  fill  string  */ 

{ 

if  (kbhit ( ) ) 

{ 

ch  =  (char) getch { ) ; 
if  (ch  ==  27) 
return; 

} 

while  (CheckQueue(&cCbl) !=CHARACTERS_WAITING)  /*  Check  IRQ  buffer  for 
chars  */ 


rcvd_st ring [ i ]  =  GetCharacter (&cbl ) ; 
printf ("."); 

/*  print f ( "exited  while  loop!  \n");  */ 

) 

printf ("The  received  string:  %s  \n",  rcvd_string  ); 
f printf (fp,  "The  received  string:  %s",  rcvd_string  ); 
CloseCom  ( £fCbi  )  ; 

DropDTR (icbl ) ;  /*  Disable  Data  Terminal  Ready  */ 

/*  printf ( "we 've  reached  CloseCom  and  DropDTR.  \n");  */ 
}  /»  end  big  for -loop  */ 

f close ( fp) ; 
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printf("just  before  final  brace.  \n"); 

}  /*  End  of  Main  */ 

5.  HAMMING  ENCODER  DIVETRACKER  TRANSMITTER 

/*  Hamming  Encoder  by  Stephen  P.  Reimers  */ 

/*  No  error  injection  routine  -  errors  are  from  acoustic  channel  */ 

/*  Code  liberally  borrowed  from  TERMINAL. C  by  Adrian  J.  Michaud  */ 

/*  Compiled  using  Borland  C++  at  command  line  */ 

#include  <string.h> 
tinclude  <stdio.h> 

#include  <conio.h> 

#include  <stdlib.h> 
tinclude  <math.h> 

#include  <time.h> 

#include  <dos.h> 

# include  ''promodem. h" 

#define  DECODED_STR_LEN  52 
#define  ENCODED_STR_LEN  76 

FILE  *fp; 

void  hamming_encoder (char  input_string[ ] ,  char  encoded_string [ ] ) ; 
void  main (void) ; 

void  main (void) 

{ 

char  filename(20] ; 

char  main_input_string  [DECODED_STR_LEN]  =  "The  purpose  of  computing  is  insight 
not  numbers!!"; 

char  xmit_encoded_string [ENCODED_STR_LEN] ; 
int  i,  count; 
int  repetitions; 
char  ch; 

AJMS  cbl; 

unsigned  int  irq=0,  basG_address=0; 
char  com_port[80]  =  "1"; 
char  baud_rate [ 80 ]  =  "4800"; 
long  baudRate=0; 
int  delayl,  delay2; 

print f ( "Enter  name  of  record  file:.  "); 
gets ( filename) ; 

if  (  (  fp  =  fopen  (filename,  "w"))  ==  NULL)  . 

{ 

fprintf (stderr,  "Error  opening  file  %s.  ",  filename); 
exit  (1)  ■; 

} 


print f ( "Enter  number  of  repetitions:  "); 
fprintf ( fp, " \nEnter  number  of  repetitions:  "); 
scanf("%d",  &repeti tions) ; 
fprintf  (fp,  "%d",  repetitions); 

/*  initialize  arrays  with  all  zeros  */ 
for  {  i  =  0;  i  ENCODED_STR_LEN;  i++  ) 
xmi t_encoded_string 1 i ]  =  0; 

while  (!irq  &&  ! base_address ) 

{ 

/*  print f { "Enter  Com  port  [1  or  2]:  "); 
gets (com_port ) ;  */ 

if  ( st rstr ( com_port ,  "1")) 

{ 
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} 


base_address  =  0x3f8; 
i rq  =  4 ; 


else 

if  (strstr (com_port ,  "2"}) 

{ 

base_address  =  0x2f8; 
irq  =  3; 

) 

} 

#define  BUFFER_SIZE  4096  /*  Use  a  4K  IRQ  Buffer  */ 

SetupControlBlock  (Sccbl  ,  base_address  ,  irq  ,  BUFFER_SIZE)  ; 

if  (OpenCom(&cbl)  !=  SUCCESSFUL)  /*  Open  Com  Port  */ 

{ 

printf ( "\nCan' t  Open  Com  Port!"); 
return; 

} 

baudRate  =  atol (baud_rate) ; 

SetBaudRate (&cbl ,  baudRate);  /*  Sets  up  Baud  Rate  */ 

SetDataFormat (&cbl,  BITS_8 1 NO_PARITY ! STOP_BITS_l ) ;  /*  8-N-l  */ 

if  (SetFIFOMode(&cbl)  ==  FIFO^ENABLED)  /*  Enable  16550  if  any  */ 

{ 

SetFIFOTriggerLevel (&cbl,  FIFO_16_TRIGGER) ;  /*  Turn  on  16  byte  RCVR  FIFO  */ 
printf ("\nUART  is  a  16550!  FIFO's  Enabled . \n" ) ; 

} 

/*  else  printf  (''\nUART  is  a  16540  or  8250. \n");  */ 

/*  if  (GetCTSRTSStatus(gtCbl)  ==  ENABLED)  */  /*  Check  if  CTS/RTS  is  on  */ 

/*  printf  ( ''XnCTS/RTS  Hardware  Handshaking  Enabled! \n"  )  ; 
else 

printf ("\nCTS/RTS  Hardware  Handshaking  Disabled! \n" ) ;  */ 

printf {" \nLoad  ANSI. SYS  if  you  wish  to  display  ANSI.Xn"); 
printf ("\nPress  [ESC]  to  Exit  this  Terminal  Program, . \n" ) ;  */ 


printf ("This  is  the  input  string:  %s  \n",  main_input_string  ); 
fprintf(fp,  "\nThe  input  .string:  %s  \n",  main_input_string  ); 

hamming_encoder (main_input_string,  xmit__encoded_string  ); 

/*  printf ("This  is  the  xmi t_encoded_string  (w/o  errors):  %s  \n", 
xmit_encoded_string  );  */ 

for  (count  =  0;  count  <  repetitions;  count++) 

{ 

print f ( "Cycle  number:  %d  \n",  count+1); 
fprintf(fp,  "Cycle  number:  %d",  count+1); 


sleep (3); 

for  (i  0;  i  <  ENCODED_STR_LEN; 
{ 

SendCharacter (&cbl ,  (unsigned 
SendCharacter (&cbl ,  (unsigned 
for  (delayl=0;  delay!  •:  1500; 

1 

for  (delay2  =  0;  delay2  v 


i=i+2) 

char) xmi t_encoded_string [i]); 
char) xmit_encoded_string [ i+1 ] ) ; 
delayl++ } 

500;  delay2++) 


}  ; 

if  (kbhi t ( ) ) 
{ 
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ch  =  (char)  getchO; 
if  (ch  ==  27)  exit (1) ; 

} 

) 

}  /*  End  of  for  loop  to  go  repetition  times  */ 
CloseCom(£ccbl)  ; 

DropDTR (&cbl ) ;  /*  Disable  Data  Terminal  Ready  */ 

f close (fp); 


void  hamming_encoder (char  input„string [ ] ,  char  encoded_string [ ] ) 

{ 

unsigned  msg_charl,  msg_char2; 

unsigned  mla,  m2a,  m3a,  m4a,  m5a,  m6a,  m7a,  m8a,  pla,  p2a,  p3a,  p4a; 
unsigned  mlb,  m2b,  m3b,  m4b,  m5b,  m6b,  m7b,  m8b,  plb,  p2b,  p3b,  p4b; 

/*  long  int  coded_charl,  coded_char2;  */ 

/*  char  coded_c,  coded_d,  coded_e;  */ 
unsigned  coded_c,  coded_d,  coded_e; 
char  cde_string [4 1 ; 
int  i,  index,  n; 

/*  initialize  cde_string  to  all  zeros,  */ 
for  (  i=0;  i  <  4;  i-i-+  ) 
cde^string [i ]  =  0; 

n  =  strlen ( input_string) ; 
if  { (n%2)  !=  0) 

{ 

strcat (input_string,  "  ; 

n++  ; 

} 


/*  printf  ("The  length  of  the  string  is  %d.  \n",  n) ;  */ 

/♦  parse  thru  current_string,  two  characters  at  a  time  */ 

for  (i=0;  i<  n;  i=i+2)  /*  positions  0  to  n-1  */ 

{ 

/*  msg_charl  is  one  character,  msg_char2  is  second  character  */ 
/*  now  loop  through  and  take  apart  msg_charl,  then  msg_char2  */ 
/*  These  are  the  same  8  bits,  but  different  types.  */ 
msg_charl  =  msg_char2  =  0; 
msg_charl  =  (int)  input_string [ i ] ; 
msg_char2  =  (int)  input_string [ i+1 ] ; 

/*  printf ("Now  encoding  characterl  %d  \n",  msg_charl) ;  */ 


mla 

= 

m2a  =  m3a  =  m4a 

=  m5a  = 

m6a  =  m7a 

mla 

= 

(msg_charl  &  1) 

»  0; 

m2a 

= 

(msg_charl  &  2) 

»  1; 

m3a 

= 

(msg^charl  &  4) 

»  2; 

m4a 

= 

(msg_charl  &  8) 

3; 

m5a 

= 

(msg_charl  &  16) 

>>  4  ; 

m6a 

= 

(msg_charl  &  32) 

»  5; 

m7a 

= 

(msg_charl  &  64) 

'>>  6; 

m8a 

(msg_charl  &  128 

)  >-  7; 

p  1  a 

p2a  =  p3a  =  p4a 

=  Ti; 

pla 

= 

mla  ^  m2  a  m4a 

^  mSa  "" 

m  /  a ; 

p2a 

= 

mla  ^  m3a  ^  m4a 

^  m6a 

m7a ; 

p3a 

= 

m2a  ^  m3a  m4a 

m8a; 

p4a 

mSa  ^  m6a  ^  m7a 

m8a  ; 
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/*  this  is  where  the  Hamming  code  gets  inserted  */ 

/*  coded_charl  =  0;  */ 

/*  coded_charl  =  (  pla  +  (p2a  «  1)  +  (mla  «  2)  +  {p3a  «  3)  + 

{m2a  «  4)  +  (m3a«  5)  +  (m4a  «  6)  +  (p4a  «  7)  + 

(m5a  «  8)  +  (m6a  «  9)  +  (m7a  <<  10)  +  (m8a  «  11));  */ 

/*  printf("This  is  the  encoded  first  char:  %x  \n",  coded_charl ) ;  */ 
printf("The  first  character  with  parity  bits  added  is  now: 
%d%d%d%d%d%d%d%d%d%d%d%d  \n",  m8a,  m7a,  m6a,  mSa,  p4a,  m4a,  m3a,  m2a,  p3a, 
mla,  p2a,  pla) ;  */ 

/*  printf("Now  encoding  character2  %d  \n",  msg_char2);  */ 


mlb 

= 

m2b  =  m3b  =  m4b 

=  m5b  =  m6b 

mlb 

= 

(msg_char2  &  1) 

»  0; 

m2b 

(msg_char2  &  2) 

»  1; 

m3b 

= 

(msg_char2  &  4) 

»  2  ; 

m4b 

(msg_char2  &  8) 

»  3; 

m5b 

= 

(msg__char2  &  16) 

»  4; 

m6b 

= 

(msg_char2  &  32) 

»  5; 

m7b 

= 

(msg_char2  &  64) 

»  6; 

m8b 

= 

(msg_char2  &  128)  >>  7; 

plb 

= 

p2b  =  p3b  =  p4b 

=  0; 

plb 

mlb  ^  m2b  ^  m4b 

m5b  ^  m7b; 

p2b 

mlb  ^  m3b  m4b 

^  m6b  ""  m7b; 

p3b 

= 

m2b  ''  m3b  m4b 

^  m8b; 

p4b 

= 

m5b  m6b  ^  m7b 

^  m8b; 

/*  this  is  where  the  Hamming  code  gets  inserted  */ 

/*  coded_char2  =  0;  */ 

/*  coded_char2  =  {  plb  +  (p2b  «  1)  +  (mlb  «  2)  +  (p3b  «  3)  + 

(m2b  «  4)  +  {m3b  «  5)  +  (m4b  «  6)  +  (p4b  «  7)  + 

(m5b  <<  8)  +  (m6b  «  9)  +  {m7b  «  10)  +  {m8b  <r<  11));  */ 

/*  printf("This  is  the  encoded  second  character:  %x  \n",  coded_char2 ) ;  */ 

/*  printf(*The  second  character  with  parity  bits  added  is  now: 
%d%d%d%d%d%d%d%d%d%d%d%d  \n* ,  m8b,  m7b,  m6b,  m5b,  p4b,  m4b,  m3b,  m2b,  p3b, 
mlb,  p2b,  plb) ;  */ 


/*  now  create  coded_c,  d,  and  e  of  type  char  */ 
coded_c  =  coded_d  =  coded_e  =  0; 

coded_c  =  ( (m8a  «  7)  +  (m7a  «  6)  +  (m6a  «  5)  +  {mSa  «  4)  + 

(p4a  «  3)  +  {m4a  «  2)  +  (m3a  <<  1)  +  m2a) ; 

/*  printf  ( ''coded_c :  %d%d%d%d%d%d%d%d  \n",  m8a,  m7a,  m6a,  mSa,  p4a,  m4a, 
m3 a,  m2a);  */ 

coded_d  =  (  (p3a  «  7)  +  {mla  «  6)  +  (p2a  *<<  5)  +  (pla  «  4)  + 

(m8b  «  3)  +  {m7b  «  2)  +  {m6b  <<  1 )  +  mSb)  ; 

/*  printf ( "coded^d :  %d%d%d%d%d%d%d%d  Xn" ,  p3a,  mla,  p2a,  pla,  m8b,  m7b, 
m6b,  mSb) ;  * / 

coded_e  =  (  (p4b  <<7)  +  (m4b  «  6)  +  (m3b  <<  5)  +  (m2b  «  4 )  -f 

(p3b  3)  (mlb  2)  ^  {p2b  «-  1)  +  plb); 

/*  print f { "coded_e :  %d%d%d%d%d%d%d%d  \n",  p4b,  m4b,  m3b,  m2b,  p3b,  mlb, 
p2b,  plb] ;  */ 

/*  printf(  "the  coded_c,  coded_d  and  coded_e  chars  are  here:  \n  %x  %x 
%x  \n  ",  coded_c,  coded_d,  coded_e);  */ 

/*  create  small  string  cde_strinq  out  of  the  coded_c,  d,  &  e  chars  */ 

for  {  index.  =  0;  index  <  3;  inde>:  +  +)  /*  zero  array  */ 

cde_stringi index]  =  0; 
cde_st ring [ 0 1  =  coded_c; 
cde_string ( 1 ]  =  coded_d; 
cde_string [ 2 ]  =  coded_e; 

/*  Lets  look  at  our  2  original  characters  which  is  now  a  3  character  string 
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*/ 

/*  printf("This  is  our  3  character  encoded  string:  %x  %x  %x  \n", 
cde_string [0] ,  cde_string ( 1 ] ,  cde_string [2 ] ) ;  */ 

/*  now  we  build  the  encoded_string  out  of  the  cde_string  */ 

/*first  test  for  an  empty  string  */ 
if  (strlen {encoded_string) ==0 ) 

{ 

/*  printf("The  length  of  string  encoded_string  is  Zero,  \n");  */ 
strcpy (encoded_string,  cde_string) ; 

/*  printf{"The  encoded_string  now  looks  like  this:  %s  \n", 
encoded_string) ;  */ 

} 

else 

{ 

/*  printf ( "going  to  the  else  clause,  strlen  >0.  \n");  */ 
strcat  (encoded_string,  cde_string) ; 

} 


}  /*  end  of  huge  for-loop  */ 

/*  printf ("the  length  of  encoded_string  is  %d  \n",  strlen (encoded_string) ) ;  */ 
/*  the  string  is  now  encoded.  */ 

} 

/*  End  of  Hamming  Encoder  */ 

6.  HAMMING  DECODER  DIVETRACKER  RECEIVER 

/*  HAMMRCVR.C  Hamming  DECODER  by  Stephen  P.  Reimers  */ 

/*  Serial  code  liberally  borrowed  from  */ 

/*  TERMINAL, C  by  Adrian  J.  Michaud  */ 

#include  <string.h> 
tinclude  <stdio,h> 

#include  <conio.h> 

#include  <stdlib.h> 

#include  "promodem. h" 
tdefine  DECODE D_STR_LEN  52 
#define  ENCODE D_STR_LEN  76 
int  total_errors_corrected  =  0; 

void  hamming_decoder (char  encoded_string [ ) ,  char  error_string [ ] ,  char 
decoded_string [ 1 ) ; 
void  clear_kb (void) ; 
void  main (void)  ; 

FILE  *fp; 

void  main (void) 

{ 

char  filename [20 ] ; 

char  rcvd_encoded__string{ENCODED_STR_LEN]  ; 
char  rcvd_decoded_string(DECODED_STR_LEN]  ; 
char  corrected_output_string[DECODED_STR_LEN] ; 

int  count  =  0; 
int  i,  a; 
int  repetitions; 
char  ch; 

AJMS  cbl ; 

unsigned  int  irq=0,  base_address=0 ; 
char  com._port  ( 80 1  =  "1"; 
char  baud_rate I  80 ]  =  "4  800"; 
long  baudRate=0; 

print f ( "Enter  name  of  record  file; 
gets ( filename) ; 
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if  (  (fp  =  f open (filename,  "w" ) )  ==  NULL) 

{ 

fprintf (stderr,  "Error  opening  file  %s.",  filename); 
exit (1) ; 

} 

/*  printf { "Enter  comm  port  to  use:"); 
gets  {com_port )  •; 
printf ("Enter  baud  rate:  "); 
fprintf (fp,  "\nEnter  baud  rate:  "); 
gets (baud_rate) ; 

fprintf (fp,  "%s",  baud_rate) ;  */ 
printf ( "Enter  number  of  repetitions:  ") ; 
fprintf (fp, "\nEnter  number  of  repetitions:  "); 
scanf("%d",  &repetitions) ; 
fprintf (fp,  "%d",  repetitions); 

for  (co.unt  =  0;  count  <  repetitions;  count  +  +  ) 

{ 

printf ( "Cycle  number:  %d  \n",  count+1); 
fprintf (fp,  "\nCycle  number:  %d  \n",  count+1); 

/*  initialize  variables  */ 
for  (  i=0;  i  <  ENCODED_STR_LEN;  i++  ) 
rcvd_encoded_string (i ]  =  0; 

for  (  i=0;  i  <  DECODED_STR_LEN;  i++  ) 

{ 

rcvd_decoded_string [i ]  =  0; 
corrected_output_string [i ]  =  0; 

} 

while  (!irq  &&  !base_address) 

{ 

if  (strstr (cora_port,  "1")) 

{ 

base_address  =  0x3f8; 
i  rq  =  4  ; 

} 

else 

if  (strstr {com_port ,  "2")) 

{ 

base_address  =  0x2f8; 
i rq  =  3 ; 

} 

} 

#define  BUFFER_SIZE  4096  /*  Use  a  4K  IRQ  Buffer  */ 

SetupControlBlock (&cbl  ,  base_address  ,  irq  ,  BUFFER_SIZE) ; 

if  (OpenCom (&cbl)  !=  SUCCESSFUL)  /*  Open  Com  Port  */ 

{ 

printf ( "\nCan' t  Open  Com  Port’"); 
return; 

} 


while  (IbaudRate)  /*  Obtain  desired  Baud  Rate  */ 

{ 

baudRate  =  atol (baud_rate) ; 

} 

SetBaudRate f&cbl ,  baudRate);  /*  Sets  up  Baud  Rate  */ 
SetDataFormat {&cbl ,  BITS_8 !NO„PARITY I STOP_BITS_l ) ;  /*  8-N-l 


if  (SetFIFOMode(&cbl)  ==  FI FO^ENABLED)  /*  Enable  16550  if  anv  */ 
{ 
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SetFIFOTriggerLevel  (&cbl,  FIFO_l 6_TRIGGER)  ;  /*  Turn  on  16  byte  RCVR  FIFO 
V 

printf { " \nUART  is  a  16550!  FIFO's  Enabled . \n" ) ; 

} 

/*  else  printf ("\nUART  is  a  16540  or  8250. \n");  */ 

if  (GetCTSRTSStatus (&cbl)  ==  ENABLED)  /*  Check  if  CTS/RTS  is  on  */ 
printf ("CTS /RTS  Hardware  Handshaking  Enabled! \n" ) ; 
else 

printf ( "\nCTS/RTS  Hardware  Handshaking  Disabled! \n" ) ; 

/*  printf (" \nLoad  ANSI. SYS  if  you  wish  to  display  ANSI.\n"); 
printf ("\nPress  [ESC]  to  Exit  this  Terminal  Program. . \n" ) ;  */ 

for  (  i=0;i  <  ENCODED_STR_LEN;  i++  )  /*  Loop  to  fill  string  */ 

{ 

if  (kbhitO) 

{ 

ch  =  (char) getch { ) ; 
if  (ch  ==  27) 
return; 

} 

while  (CheckQueue(&cCbl) !=CHARACTERS_WAITING)  /*  Check  IRQ  buffer  for 
chars  */ 

/ 

rcvd_encoded_string [i ]  =  GetCharacter (&cbl ) ; 
printf  {''.")  ; 

/*  printf ( "exited  while  loop!  \n");  */ 

} 

hamming_decoder (rcvd_encoded_string,  rcvd_decoded_string, 
corrected_output_string) ; 

printf ("The  received  decoded  string:  %s  \n",  rcvd_decoded_string  ); 
fprintf (fp,  "The  received  decoded  string:  %s",  rcvd_decoded_string  ); 

printf ("The  corrected  decoded  string:  %s  \n",  corrected_output_string  ); 
f printf ( fp, " \nThe  corrected  decoded  string:  %s  \n",  corrected_output_string 


CloseCom  (Stcbl )  ; 

DropDTR  (ScCbl )  ;  /*  Disable  Data  Terminal  Ready  */ 

/*  printf ( "we 've  reached  CloseCom  and  DropDTR .  \n");  */ 

}  !*  end  big  for-loop  */ 

print f ( "Total  errors  corrected:  %d  \n",  total_errors_corrected) ; 
fprintf(fp,  "\nTotal  errors  corrected:  %d  \n",  total_errors_corrected) ; 
f close { fp) ; 

printf ("just  before  final  brace.  \n"); 

}  /*  End  of  Main  */ 

/♦Hamming  12/8  Decoder  */ 

void  hamming_decoder (char  encoded_string ( ] ,  char  error_st ring { ] ,  char 
decoded_st ring [ J ) 

i 

unsigned  msg_charl,  msg_cha.r2  ; 

unsigned  mla,  m2a,  m3a,  m4a,  mSa,  mba,  m7a,  m6a,  pla,  p2a,  p3a,  p4a; 
unsigned  mlb,  m2b,  m3b,  m4b,  mSb,  m6b,  m7b,  m8b,  plb,  p2b,  p3b,  p4b; 
unsigned  syndromel,  syndrome2 ,  new_syndromel ,  new_syndrome2 ; 
unsigned  new_pla  =  0,  new_jj2a  =  0,  new_j^3a  =  0,  new_p4a  =  0; 
unsigned  new_plb  =  0,  new_p2b  =  0,  new_p3b  =  0,  new_p4b  =  0; 
unsigned  coded_c,  coded_d,  coded_e; 
char  a_string[2],  b_string[2]; 
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unsigned  error_locationl ,  error_location2 ; 
int  i,  b,  n,  error_count  =  0; 
int  index  =  0; 

/*  now  get  the  encoded_string,  and  start  decoding  it  */ 

/*  printf("the  encoded_string :  %s  \n",  encoded_string) ;  */ 

n  =  strlen (encoded_string) ; 

/*  printf ("length  of  encoded_string  is  %d  \n",  n) ;  */ 

if  { (n%3)  !=  0) 

{ 

fprintf(fp,  "\nWARNING:  encoded  string  is  not  evenly  divisible  by  3!  \n"); 
printf ("WARNING:  encoded  string  is  not  evenly  divisible  by  3!  \n"); 
if  ((n%3)  ==  1) 

{ 

strcat(  encoded_string,  "  ");  /*append  2  spaces*/ 

n  =  n+2; 

} 

else  /*n%3  must  equal  2,  so  we  only  need  one  space  */ 

{ 

strcat(  encoded^string^  "  "); 
n++ ; 

) 

}/*end  of  if  clause  */ 

/*  parse  thru  output_string,  three  characters  at  a  time  */ 

for  (i  =  0;  i  <  n;  i  =  i+3)  /*  positions  0  to  n-1  */ 

{ 

/*  initialize  both  strings  to  all  zeros.  */ 
for  (  b  =  0;  b  <  2;  b++  ) 
a_string[b]  =  0; 
for  (  b  =  0;  b  <  2;  b++  ) 
b_string[b]  =  0; 

/*  printf ("this  is  the  nulled-out  a_string:  %s  \n",  a_string) ; 
printf ("this  is  the  nulled-out  b^string;  %s  \n",  b^string) ;  */ 

coded__c  =  (int)  encoded_string [ i )  ; 
coded_d  =  (int)  encoded_string[i+l) ; 
coded_e  =  (int)  encoded_string[i+2] ; 

/*  now  we  have  to  get  12  bits  back  out  of  the  3  chars,  which  are  the 
original  message  bits  plus  the  parity  bits.  */ 


mla 

= 

m2a  =  m3a 

=  m4a  =  m5a  =  m6a  =  m7a  =  m8a  =  0; 

pla 

p2a  =  p3a 

=  p4a  =  plb  =  p2b  =  p3b  =  p4b  =  0; 

mlb 

= 

m2b  =  m3b 

=  m4b  =  mSb  =  m6b  =  m7b  =  m8b  =  0; 

mSa 

- 

(coded_c 

& 

128)  »  7; 

m7a 

(coded_c 

& 

64)  »  6; 

m6a 

= 

(coded_c 

& 

32)  »  5; 

m5a 

= 

(coded_c 

& 

16)  »  4; 

p4a 

= 

(coded_c 

& 

8)  »  3; 

m4a 

= 

(coded_c 

& 

4)  »  2; 

m3a 

= 

(coded_c 

& 

2)  »  1; 

m2a 

= 

( coded_c 

1)  »  0; 

p3a 

( coded_d 

& 

128)  »  7; 

mla 

= 

(coded_d 

& 

64)  »  6; 

p2a 

= 

( coded_d 

& 

32)  >'>  5; 

pla 

= 

(coded_d 

& 

16)  »  4; 

m8b 

- 

(coded_d 

& 

8  )  >•>  '  3  ; 

m7b 

= 

(coded_d 

& 

4)  »  2; 

m6b 

= 

(coded_d 

U 

2)  »  1; 

m5b 

( coded_d 

1)  »  0; 

p4b 

(coded__e 

& 

128)  v'-  7; 

m4b 

=: 

(coded_e 

& 

64)  6; 

m3b 

= 

(coded_e 

& 

32)  »  5; 
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m2b  =  {coded_e  &  16)  »  4; 
p3b  =  (coded_e  &  8)  »  3; 

mlb  =  (coded_e  &  4)  »  2; 

p2b  =  (coded_e  &  2)  »  1; 

plb  =  (coded_e  &  1)  >>  0; 

msg^charl  =  msg_char2  =  0; 

msg_charl  =  {  {in8a  «  7)  +  (m7a  «  6)  +  (m6a  «  5)  +  (m5a  «  4)  + 

(m4a  <<  3)  +  {in3a  «  2)  +  {m2a  «  1)  +  mla); 

msg_char2  =  {  (in8b  «  7}  +  (in7b  «  6)  +  (mSb  «  5)  +  (mSb  «  4)  + 

(m4b  <<  3)  +  (in3b  «  2)  +  (m2b  «  1)  +  mlb); 


/*  Create  the  string  of  UNCORRECTED  incoming  characters.  */ 

error_stringlindex]  =  msg_charl; 

..  error_string [ ipdex+1 ]  =  msg_char2; 
index  =  (index- +2); 

/*create  the  syndrome  word  for  the  characters  received  */ 
syndromel  =  syndrome2  =  0 ; 

syndromel  =  { (p4a  «  3)  +  (p3a  «  2)  +  {p2a  «  1)  +  pla); 

/*  printf("This  is  received  syndromel:  %x  \n",  syndromel);  */ 

syndrome2  =  ( (p4b  «  3)  +  (p3b  «  2)  +  (p2b  «  1)  +  plb) ; 

/*  printf("This  is  received  syndrome2 :  %x  \n",  syndrome2 ) ;  */ 

/*  recompute  the  parity  bits  from  the  received  characters  */ 

mla  =  m2a  =  m3a  =  m4a  =  mSa  =  m6a  =  m7a  =  m8a  =  0; 

new_pla  =  new_p2a  =  new_p3a  =  new_jp4a  =  0; 

new_plb  =  new_p2b  =  new_p3b  =  new_p4b  =  0; 

mlb  =  m2b  =  m3b  =  m4b  =  m5b  =  m6b  =  m7b  =  m8b  =  0; 

mla  =  (msg_charl  &  1)  »  0; 

m2a  =  (msg_charl  U  2)  »  1; 

m3a  =  {msg_charl  &  4)  »  2; 

m4a  =  (msg_charl  &  8)  »  3; 

m5a  =  (msg_charl  &  16)  »  4; 

m6a  =  (msg_charl  &  32)  »  5; 

m7a  =  (msg_charl  &  64}  »  6; 

m8a  =  (msg_charl  &  128)  »  7; 

new_pla  =  mla  ^  m2a  m4a  m5a  ^  m7a; 

new_p2a  =  mla  "  m3a  "  m4a  m6a  "  m7a; 

new_p3a  =  m2a  ''  m3a  ^  m4a  ^  m8a; 

new_p4a  =  m5a  m6a  ^  m7a  ^  m8a; 

mlb  =  {msg_char2  &  1)  »  0; 

m2b  =  (msg_char2  &  2)  >>  1; 

m3b  =  {msg_char2  &  4)  »  2; 

m4b  =  (msg_char2  &  8)  »  3; 

m5b  =  (msg_char2  &  16)  4; 

m6b  =  (msg_char2  &  32)  »  5; 

m7b  =  (msg_char2  &  64}  '*>  6; 

m8b  =  (msg_char2  &  128)  7; 

new_jjlb  =  mlb  ^  m2b  m4b  m5b  ^  m7b; 

new_p2b  =  mlb  m3b  ^  m4b  ''  m6b  m7b; 

new__p’3t  -  m2b  ^  m3b  ''  m4b  ""  m8b; 

new_p4b  =  m5b  "  m6b  m7b  "  m8b; 

new_syndromel  =  new_syndrome2  =  0; 

new_syndromel  =  {  (new__p4a  3)  +  fnew_p3a  «  2)  +  (new_p2a  <<  1)  + 
new_pla) ;  . 

/'  print: f  ( "This  is  new_syndromel :  ^oX  \n",  new^syndromel )  ;  */ 
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new_syndroine2  =  ( {new_p4b  «  3)  +  (new_p3b  «  "2)  +  (new_p2b  «  1)  + 
new_plb) ; 

/*  printf("This  is  new_syndrome2 :  %x  \n",  new_syndrome2 ) ;  */ 

/*now  check  to  see  if  the  syndrome  words  are  the  same.*/ 

/*  If  not,  perform  bit-flipping  on  bit  in  error.  */ 

if  { {new_syndromel  syndromel)  !=  0) 

{ 

error_locationl  =  ( ( (new_p4a  ^  p4a)  «  3)  +  { (new_p3a  ^  p3a)  «  2}  + 
(  (new_p2a  ^  p2a)  «  1)  +  (newjla  ^  pla)  )  ; 

/*  printf ("Error  at  location  %d.  \n",  error_locationl ) ;  */ 

error_count++ ; 

switch  (error_locationl ) 

{ 

case  1: 

{ 

pla  =  (pla  ^  1 ) ; 
break; 

} 

case  2: 

{ 

p2a  =  (p2a  ^  1 )  ; 
break; 

} 

case  3: 

{ 

mla  =  (mla  1 )  ; 

break; 

} 

case  4: 

{ 

p3a  =  (p3a  1)  ; 

break; 

} 

case  5 : 

{ 

m2a  =  (m2a  ^1); 
break; 

} 

case  6 : 

{ 

m3a  =  (m3 a  1); 

break; 

} 

case  7 : 

{ 

m4a  =  (m4a  1)  ; 

break; 

} 

case  8: 

{ 

p4a  =  (p4a  ^  1) ; 
break; 

} 

case  9: 

{ 

m5a  =  (mSa  1 )  ; 

break ; 

} 

case  10: 
i 

m6a  =  {m6a  1 )  ; 

break ; 

} 

case  11 : 

{ 
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Tn7a  =  {m7a  1)  ; 

break; 

} 

case  12 : 

{ 

inSa  =  {m&a  1)  ; 

break; 

} 

default : 

{ 

print f ( "something  is  going  wrong  in  case  for  syndromel .  \n"); 
} 

}  /*  end  of  switch  statement.  */ 
msg_charl  =  0; 

insg_charl  =  (  (m8a  «  7)  +  (m7a  «  6)  +  (m6a  «  5)  +  (m5a  «  4)  + 
(m4a  «  3)  +  (m3a  «  2)  +  (m2a  «  1)  +  mla) ; 

/*  printf ( "corrected  character  is:  %c  \n" ,  msg_charl);  */ 

} 

/*  printf ("we  made  it  to  the  end  of  the  if  block.  \n");  */ 


b_string[0]  =  msg_charl; 
if  (strlen (decoded_string)  ==  0) 

{ 

strcpy (decoded_string,  b_string) ; 

} 

else 

{ 

strcat (decoded_string/  b_string) ; 

} 

if  { (new_syndrome2  ^  syndrome2)  !=  0) 

{ 

error_location2  =  {  ( (new_p4b  p4b)  «  3)  +  (  (new_p3b  ^  p3b)  «  2)  + 
(  {new_p2b  ^  p2b)  «  1)  +  (new__plb  ^  plb)  )  ; 

/*  printf ( "Error  at  location  %d.  \n",  error_location2 } ;  */ 
error_count++ ; 

switch  (error_location2 ) 

{ 

case  1 : 

{ 

plb  =  (plb  ^  1); 
break; 

} 

case  2; 

{ 

p2b  =  (p2b  ""  1)  ; 
break; 

} 

case  3 : 

{ 

mlb  =  (mlb  ^  1) ; 
break ; 

} 

case  4 : 

{ 

p3b  =  (p3b  ^  1) ; 
break ; 

) 

case  5  : 

{ 

m2b  =  (m2b  ^  1 ) ; 
break; 

} 

case  6: 

{ 

m3b  =  (m3b  1)  ; 
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break; 

} 

case  7 : 

{ 

in4b  =  [mAh  ^  1)  ; 
break; 

) 

case  8: 

{ 

p4b  =  (p4b  ""  1 )  ; 
break; 

) 

case  9: 

{ 

m5b  =  (iti5b  ^  1)  ; 
break; 

} 

case  10: 

{ 

rn6b  =  (m6b  "  1)  ; 
break; 

} 

case  11 : 

{ 

m7b  =  (ni7b  1)  ; 
break; 

} 

case  12  : 

{ 

m8b  =  (m8b  ^  1) ; 
break; 

} 

default: 

{ 

printf ( "something  is  going  wrong  in  case  for  syndrome2 .  \n") 

} 

}  /*  end  switch  block  */ 

msg_char2  =  ( (m8b  «  7)  +  {m7b  «  6)  +  (m6b  «  5)  +  {m5b  «  4}  + 
(m4b  «  3)  +  (m3b  «  2)  +  (m2b  «  1)  +  mlb) ; 

/*  printf ( "corrected  character  is:  %c  \n",  msg_char2) ;  */ 

) 

a_string[0]  =  msg_char2; 
if  (strlen (decoded^string)  ==  0) 

{ 

strcpy (decoded^string,  a_string) ; 

} 

else 

{ 

street  (decoded^string,  a__string}  ; 

} 


} 

print f ( "Error  count  for  string:  %d  \n",  error_count) ; 
fprintf(fp,  "Error  count:  %d\n",  error_count ) ; 
total_errors_corrected  =  total_errors_corrected  +  error_count; 

}  /*  End  function.  */ 
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APPENDIX  B:  PROGRAMMING  DIVETRACKER 

A  fairly  complete  user’s  manual  is  currently  included  with  the  purchase  of  the  Desert 
Star  Systems  Divetrackers,  but  some  changes  in  the  manual  have  not  kept  up  with  changes 
in  the  hardware.  According  to  Marco  Flagg,  CEO  of  Desert  Star  Systems,  this  situation  is 
being  corrected.  In  the  interim,  this  appendix  is  intended  to  provide  a  step-by-step 
programming  guide  for  the  Divetrackers  purchased  by  NFS  for  thesis  research  and 
incorporation  into  the  Phoenix  AUV  for  navigation  and  communication. 

The  Divetracker  series  components  are  built  using  identical  microprocessor  and 
modem  hardware.  The  only  difference  between  the  DTl-D-S  Diver’s  waterproof  station 
(Figure  11-7)  and  the  DTI -Dry  surface  station  (Figure  11-8)  is  the  enclosure  the  units  are 
mounted  in,  and  the  way  the  two  units  are  configured  for  running  the  SMARTDIVE 
application  program.  The  only  difference  between  the  DTl-D-S  and  the  DTl-R-S  remote 
unit  is  the  lack  of  a  LCD  display  and  data  entry  pad.  The  only  difference  between  the 
DTl-D-S  unit  and  the  DTl-Mod  is  the  DTl-Mod’s  lack  of  a  waterproof  enclosure,  pressure 
transducer,  and  depth  transducer,  as  it  is  designed  to  be  mounted  in  a  waterproof  ROV  or 
AUV  housing.  The  Divetrackers  all  utilize  flash  memory  modules  to  store  the  programs 
which  they  run,  whether  it  be  SMARTDIVE,  AMODEM,  or  the  supporting  programs 
which  provide  diagnostics  or  battery  charging  functions  for  the  diver’s  station  and  the 
remote  units.  The  non-surface  stations  (diver’s  station,  remote  units)  keep  all  application 
code  in  FLASH  memory,  with  all  essential  configuration  data  stored  in  EEPROM.  As  both 
memories  are  non-volatile,  the  application  is  booted  and  configured  automatically  as  soon 
as  power  is  applied. 

Several  concepts  regarding  the  Divetrackers  must  be  understood  in  order  to  comply 
with  the  following  steps.  First,  the  Divetracker  unit  is  incapable  of  functioning  without 
having  program  code  loaded  into  it.  Prior  to  use  for  any  application,  DiveCode  must  be 
loaded  into  the  DiveTracker  units  and  that  code  configured  to  run.  At  the  time  of  this 
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Avriting,  all  DiveCode  has  been  written  and  compiled  by  Desert  Star  Systems.  Source  code 
has  not  been  made  available  to  the  public,  although  that  will  probably  change  in  the  future. 
The  existing  code  has  been  written  mainly  to  support  the  navigation  and  communications 
functions  provided  by  the  basic  SMARTDIVE  program,  as  that  is  what  the  Divetracker 
system  was  orginally  designed  for.  However,  upon  request,  code  such  as  AMODEM  was 
written  and  compiled  by  Desert  Star  Systems  specifically  for  this  thesis  research.  All 
DiveCode  is  written  in  C  and  compiled  on  an  Archimedes  DOS/MC68HC11 
cross-compiler.  One  of  the  reasons  that  Desert  Star  Systems  wrote  and  compiled  the  source 
code  was  the  high  cost  of  purchasing  the  Archimedes  Cross-Compiler. 

DiveCode  is  loaded  into  the  Divetrackers  using  a  DOS  program  named 
DrVETERM.EXE.  The  process  of  loading  code  is  outlined  in  Figure  B-1.  This  file  resides 
in  the  DTUTILS  directory  in  most  implementations  of  the  system.  DIVETERM 
communicates  with  the  DiveTracker  using  port  COM  1 .  Support  for  other  comm  ports  has 
not  yet  been  implemented  into  DIVETERM. 


Figure  B-1:  DiveTracker  test  procedure. 
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The  test  procedure  follows.  An  IBM-Compatible  PC  is  needed  which  has  a  free  COMl 
port  as  well  as  having  the  code  which  Desert  Star  Systems  supplies  with  the  DiveTracker 
loaded  onto  the  hard  disk.  This  code  comes  oh  3.5”  floppy  disks,  and  is  loaded  into  the 
computer  according  to  the  directions  given  on  the  diskettes.  The  code  will  install  itself  into 
two  different  directories;  DIVEBASE  and  DTUTILS.  Assuming  this  has  been  done 
already,  connect  the  Divetracker’s  serial  connector  to  the  PC’s  COMl  port,  using  a  DB-25 
to  DB-9  adapter  if  needed,  and  without  turning  on  the  power  to  the  Divetracker,  turn  the  PC 
on  and  let  it  boot  up  to  the  MS-DOS  operating  system  prompt.  Change  the  directory  from 
the  root  directory  to  DTUTILS,  or  if  the  PC  is  already  on,  just  change  directory  to 
DTUTILS..  Determine  the  contents  of  the  DTUTILS  directory  by  typing  DIR  followed  by 
pressing  the  ENTER  key.  Verify  that  the  desired  DiveCode  (.dc  suffix)  is  present  in  the 
DTUTILS  directory,  in  the  event  that  that  code  needs  to  be  loaded.  Once  identified,  write 
the  name  of  the  DiveCode  program  down  for  later  reference.  Execute  the 
DIVETERM.EXE  program  by  typing  DIVETERM  followed  by  pressing  the  ENTER  key. 
The  screen  shown  in  Figure  B-2  will  be  displayed. 


****DiveTenn  Vl.lO**** 

LINK  STATUS:  IDLE 

CONNECTED  TO:  NO  CONNECT 

Please  select: 

FI:  Select  COM  Port 

FIO:  Exit  DiveTerm 

X:  DiveCode  Terminal 

F2:  Select  DiveCode  Directory 

I:  Inquire  DiveTracker 

Figure  B-2:  Initial  DIVETERM  screen,  DiveTracker  OFF. 

Now  turn  on  the  DiveTracker,  either  by  supplying  power  to  the  AUV  Module,  or  by 
turning  on  the  power  switch  on  the  DTI -Dry  surface  station,  or  by  using  the  magnetic 
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pointer  in  the  case  of  the  DTl-D-S  Diver’s  station.  The  PC  display  screen  should  now  show 
the  contents  of  Figure  B-3. 


****DiveTenn  VI.  10**** 

LINK  STATUS:  ACTIVE 

CONNECTED  TO:  DiveTracker  model  DTl-DRY,  s/n  102 

MEMORY  MAP: 

00:  a.modem  VO.OO 

01:  *** 

02:  *** 

03:  <empty> 

04:  <empty> 

05:  <empty> 

06:  <empty> 

07:  <empty> 

08:  <empty> 

09:  <empty> 

10:  <empty> 

11:  <empty> 

12:  <empty> 

13:  <empty> 

14:  <empty> 

15:  <empty> 

Please  select: 

FI:  Select  COM  Port 

F2:  Select  DiveCode  Directory 

F3:  Download  DiveCode  F4:  Erase  FLASH  memory 

F5:  Select  DiveCode 

F6:  Run  DiveCode 

F7:  Set  DiveTracker  Clock  FIO:  Exit  DiveTerm  1 

M:  Set  Model  Type 

X:  DiveCode  Terminal 

<:  Receive  Calibration  Data  >:  Transmit  Calibration  Data 

Figure  B-3:  DIVETERM  screen,  DiveTracker  ON. 

The  serial  number  of  the  DiveTracker  will  be  displayed  in  the  “Connected  To”  line,  as 
shown  above.  Depending  on  the  code  already  loaded  into  the  Divetracker’s  flash  memory, 
the  pages  from  00  to  15  may  show  the  name  of  a  program,  a  series  of  asterisks  ***,  or  an 
<empty>  sign.  Each  program  takes  from  1  to  16  pages  of  flash  memory.  Before  allowing 
new  code  to  be  loaded  into  the  flash  memory,  DIVETERM  checks  to  see  if  enough  flash 
memory  is  available.  If  not  enough  space  is  available,  due  to  code  already  in  the  unit  taking 
up  the  needed  space,  DIVETERM  will  ask  whether  or  not  flash  memory  should  be  erased. 
Flash  memory  is  erased  in  bulk  and  it  cannot  be  erased  one  page  at  a  time.  Also,  if  a 
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program  takes  up  1  whole  page  and  has  one  byte  left  over,  the  second  page  it  takes  up  is 
marked  as  full  also,  even  though  it  only  has  one  byte  in  it. 

Depending  on  what  needs  to  be  done  by  running  DIVETERM,  whether  it  be  erasing 
flash  memory,  downloading  code,  or  simply  selecting  which  code  already  loaded  into  flash 
memory  should  run  when  the  DiveTracker  is  powered  up,  the  menu  shown  in  Figure  B-3 
is  where  these  options  are  selected.  In  the  example  shown,  SMARTDIVE  could  be  loaded 
into  pages  03-15  by  selecting  function  key  F3.  Upon  pressing  F3i  the  program  will  will  ask 
for  the  name  of  the  DiveCode  to  be  loaded.  Type  the  name  of  the  *.dc  file  written  down 
earlier  and  press  ENTER.  The  screen  shown  in  Figure  B-4  should  be  displayed.  Actually, 


Specify  first  FLASH  page  to  be  used  (0..15):  00 

Waiting  for  ready  signal  from  MCU... 

MCU  reports  FLASH  is  NOT  erased! 

Do  you  want  to  erase  FLASH  memory  (y/n)?  y 
Waiting  for  erase  completed... 

FLASH  is  erased! 

Now  loading  page  number  0... 

Program  7367  bytes,  last  one  at  $9fff 
Completed  99  percent  of  transfer... 

Page  programed  OK! 

Waiting  for  ready  signal  from  MCU... 

MCU  FLASH  is  erased! 

Now  loading  page  number  1... 

Program  8771  bytes,  last  one  at  $9fff 
Completed  99  percent  of  transfer... 

Page  programed  OK! 

Waiting  for  ready  signal  from  MCU... 

MCU  FLASH  is  erased! 

Now  loading  page  number  2... 


Figure  B>4:  Erasure  of  flash  memory  and  code  download. 


the  first  section  is  all  that  will  be  displayed,  up  to  the  line  that  reports  “MCU  reports 
FLASH  is  NOT  erased!”  When  prompted,  enter  a  y  for  YES  or  a  n  for  NO.  If  a  y  is  entered, 
DIVETERM  will  begin  to  erase  the  memory,  and  when  completed,  it  will  begin  to  load  the 
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code  into  the  flash  memory.  As  it  fills  each  page,  it  displays  a  status  indicator  as  shown  in 
the  lower  half  of  Figure  B-4.  Erasure  of  flash  memory  takes  about  5  minutes  and  loading 
code  into  the  flash  memory  takes  about  1  minute  per  page. 

After  code  has  been  successfully  loaded  into  the  flash  memory,  it  is  automatically 
selected  to  run  when  the  DiveTracker  is  powered  up.  However,  if  DIVETERM  is  being 
used  to  select  which  code  is  to  run,  in  the  event  that  more  than  one  program  is  loaded  into 
flash  memory,  the  same  steps  are  taken  as  described  earlier,  except  that  only  F5  and  F6  need 
to  be  pressed  to  select  and  run  the  desired  code.  When  code  is  run  using  F6,  or  X  (capital, 
as  DIVETERM  is  case  sensitive)  the  following  screen  shown  in  Figure  B-5  will  be 
displayed. 

DiveCode  Terminal: 

C:  Configure  DiveCode 
T:  Read  DiveTracker  ‘tape  drive’ 

X:  Exit  to  main  menu  (DTOS  interaction) 

a.modem  VO.OO 
<Contn)I  Mode> 


Figure  B-5:  AMODEM  execution  response  in  DiveTerm. 

Depending  on  the  application  actually  running,  the  DiveCode  Terminal  will  use  this 
screen  to  display  whatever  the  DiveTracker  is  outputting  through  its  communications  link 
to  the  PC,  whether  it  be  modem  status,  as  in  the  case  of  AMODEM.DC,  or  baseline  range 
data  from  the  baseline  in  the  case  of  SMARTDIVE.DC.  This  display  verifies  correct 
operation  of  the  DiveCode. 

The  DiveCode  Terminal  is  also  used  to  configure  the  SMARTDIVE  application. 
SMARTDIVE  sets  various  parameters  using  a  *.cfg  file  which  is  loaded  into  the  Diver’s 
station  and  AUV  module  prior  to  deployment.  This  is  in  contrast  to  the  DTI -DRY  surface 
station  which,  when  running  SMARTDIVE,  uses  a  DIVEBASE.PAR  file  to  configure  it 
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when  the  PC  is  ranning  the  DIVEBASE  application.  A  diagram  of  this  is  shown  in  Figure 
B-6.  Finally,  a  separate  terminal  program  is  used  to  actually  configure  AMODEM.DC. 


PC  running  DIVEBASE  or  otiier  Application  pro¬ 
gram  such  as  TERMINAL  or  HAMMTRAN, 
communicating  to  DiveTracker  through  serail  link 
fromCOMl. 


DiveTracker  running 
SMARTDIVE.DCor 
AMODEM.DC  which  is 
stored  in  Flash  Memory. 
SMARTDIVE  configura¬ 
tion  files  are  downloaded 
firom  PC  into  DiveTracker 
using  DrVETERM. 


Acoustic  Transducers  which 
form  baseline  for  DIVEBASE 
application.  Only  one  needed 
.  forAMODEM. 


Figure  B-6:  PC  and  DTl-DRY  Surface  Station  setup 

Any  terminal  program  will  work,  as  long  as  the  communications  port  and  baud  rate  are  able 
to  be  set  to  COMl  and  4800  baud,  respectively.  AMODEM.DC  has  two  modes  of 
operation:  Control  and  Data.  The  control  mode  is  accessed  by  either  turning  on  the 
DiveTracker  when  AMODEM.DC  is  configured  to  run,  or  by  forcing  the  DiveTracker  to 
go  into  the  Control  mode  from  the  Data' mode  by  pressing  the  plus  key  four  times  (-i-t-n-). 
This  will  not  only  transmit  the  four  plus  signs,  but  will  bring  up  the  Control  screen  shown 
in  the  lower  half  of  Figure  B-5.  Pressing  H  (for  Help)  will  display  the  parameter  settings  as 
shown  in  Figure  B-7.  The  units  for  each  of  the  settings  are  described  in  Figure  VI-3. 
Parameters  are  modified  by  pressing  the  first  letter  of  the  desired  parameter,  such  as  “S” 
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for  Speed,  then  a  value,  using  as  many  zeros  as  needed  to  left-justify  the  value  so  there  are 
as  many  digits  as  there  are  pound  signs  (#)  in  the  parameter  line.  For  example,  to  change 
pulse  length  from  1000  to  500,  enter  “L0500”  and  press  enter.  No  change  will  be  seen  until 
H  is  pressed  again,  and  then  the  new  value  will  be  shown.  After  modification  of  parameters, 
the  unit  can  be  reset  to  default  values  simply  by  turning  it  off.  When  turned  back  on,  it  will 
come  up  in  the  control  mode  Prior  to  use  as  a  modem,  it  must  be  switched  to  data  mode 
using  a  terminal  program  or  the  program  which  will  pass  data  to  and  from  the  modem. 


Press  [ESC]  to  Exit  this  Sample  Terminal  Program.. 

Use  Hayes  AT  Commands  to  Talk  to  your  modem.  If  you  don’t  get  a 
response,  try  the  other  COM  port,  or  change  your  IRQ  setting. 

? 

a.modem  VO.OO 
<Contiol  Mode> 

H 

Speed  [S#:0-4];  1 

Power  [P###:0(X)-255]:  255 
P’length  [L####:0100-5{)00]:  1000 
Gain  [G#:0-3]:  2 

T’hold  [T##:0-99]:  16 

Filter  [F#:0-5]:  0 

Checksum  [C#:0-1]:  1 

Type  <D>  for  data  exchange  mode 
Type  <+++>  to  return  to  control  mode 
Type  <Q>  to  switch  the  modem  OFF 
D 

<Data  Mode> 

The  purpose  of  computing  is  insight,  not  numbers.! 


Figure  B-7:  AMODEM.DC  Help  screen  with  parameter 
display. 
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APPENDIX  C:  ACRONYMS 


ADATS . Adjustable  Diversity  Acoustic  Telemetry  System 

AOSN . Autonomous  Oceanographic  Sampling  Network 

ASCn . American  Standard  Code  for  Information  Interchange 

ATM . Asynchronous  Transfer  Method 

AUSS . Autonomous  Underwater  Search  System 

AUV . Autonomous  Underwater  Vehicle 

BCH . Bose-Chaudhuri-Hocquenghem  (codes) 

BER . Bit  Error  Rate 

bps . bits  per  second 

BPSK . Binary  Phase  Shift  Keying 

CPU . Central  Processing  Unit 

DES . Data  Encryption  Standard 

DLL . Dynamic  Link  Library 

DCE . Data  Communication  Equipment 

DCT . Discrete  Cosine  Transform 

DPSK . . . Differential  Phase  Shift  Keying 

DSP . Digital  Signal  Processing 

DTE . .  Data  Terminal  Equipment 

ECB . Electronic  Code  Book 

FDDl . Fiber  Distributed  Data  Interface 

FSK . Frequency  Shift  Keying 

IP . Internet  Protocol 

ISI . Intersymbol  Interference 

ISO  . . . . International  Standards  Organization 

ISSM . Independent  Single  Sideband  Modulation 
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kbps . kilobits  per  second 

kHz . Kilo  Hertz 

LAN . Local  Area  Network 

LBL . Long  Baseline  (navigation  system) 

LASER . Light  Amplification  by  Stimulated  Emission  of  Radiation 

LLC . Logical  Link  Control 

MABEL . Modular  Abyssal  Benthic  Laboratory 

(MAC) . Medium  Access  Control 

MAN . Metropolitan  Area  Network 

MFSK . Multiple  Frequency  Shift  Keying 

MLE . . Maximum  Likelihood  Estimation 

NIC . Network  Interface  Card 

nm . Nautical  Mile 

OSI . Open  Systems  Interface 

PC . Personal  Computer 

PPP . Point-to-Point  Protocol 

QAM . Quadrature  Amplitude  Modulation 

QPSK . Quadrature  Phase  Shift  Keying 

RFC . Request  For  Comments 

RPC . Remote  Procedure  Call 

SBL . Short  Baselinej  (navigation  system) 

SLIP . Serial  Line  Internet  Protocol 

SNR . Signal  to  Noise  Ratio 

TCP . Transport  Control  Protocol 

UDP . User  Datagram  Protocol 

UWA . Underwater  Acoustic  (Channel) 

VHF . Very  High  Frequency 

VLF . Very  Low  Frequency 
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WWW 


World  Wide  Web 
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APPENDIX  D:  RADIO  ETHERNET  BRIDGES 


Acoustic  Local  Area  Networks  (ALANs)  must  have  an  access  point  -  a  contact  point 
to  a  pre-existing  network  infrastructure,  which  is  usually  a  higher  speed  wired  or  wireless 
backbone.  In  the  case  of  this  thesis  research,  the  pre-existing  network  is  the  Internet,  and  it 
can  be  accessed  via  an  RF  link  instead  of  a  wired  link.  The  requirement  for  this  type  of  link 
is  justified  simply  by  the  cost  and  difficulty  of  running  some  sort  of  wire  or  cable  to  one  of 
the  network  nodes  which  would  act  as  a  gateway  for  the  rest  of  the  network. 

Normal  implementation  of  a  bridge  might  be  on  a  bouy  or  float  which  housed  a  power 
supply  such  as  batteries  or  a  solar  generator,  an  antenna,  and  an  acoustic  network  node  with 
its  transducers  positioned  so  as  to  best  communicate  with  the  other  submerged  network 
nodes.  In  the  implementations  of  this  type  described  in  the  research,  a  recurring  problem 
was  acoustic  interference  from  the  buoy  anchoring  hardware  which  greatly  affected  the 
acoustic  node’s  ability  to  conununicate  with  its  peers.  The  bridge’s  RF  antenna  must  be 
pointed  towards  the  shore  receiver  site,  and  arranged  so  that  it  maintains  direction,  a  feat 
not  easily  acomplished  on  a  bouy. 

During  this  thesis  research,  two  different  radio  ethemet  bridge  systems  were  available 
for  experimentation.  Although  not  utilized  specifically  with  the  Divetracker,  both  systems 
were  successfully  used  to  connect  NFS  Spanagel  Hall  to  both  the  NFS  Autonomous 
Underwater  Vehicle  Laboratory,  located  at  the  NFS  Golf  Course  Building  230,  and  the 
Hyatt  Regency  Hotel,  located  across  the  highway  from  NFS  as  shown  in  Figure  D-1.  The 
former  was  accomplished  in  order  to  provide  connectivity  to  the  network  on  which  the  NFS 
Phoenix  AUV  is  operated  from  the  main  NFS  network.  Real-time  AUV  demonstrations 
during  the  Autonomous  Vehicles  in  Mine  Countermeasures  Symposium  were  also 
transmitted  back  to  Spanagel  Hall’s  Computer  Science  Graphics  Laboratory  via  Multicast 
Backbone  (mBone)[Macedonia,  Brutzman  94],  The  latter  was  performed  to  provide 
Internet  access  to  the  Hyatt  Regency  Hotel  during  the  Interactive  3-D  Graphics  Symposium 
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[Zyda  95].  Both  systems  performed  well,  affording  connectivity  at  rates  of  800  Kbps  and 
2  Mbps  respectively,  which  was  more  than  adequate  for  each  application. 


Figure  D-1:  ARLAN  &  AIRLAN  implementation  at  NFS. 

1.  ARLAN  620 

The  system  used  first  was  the  Arlan  620,  provided  by  Monterey  Bay  Aquarium 
Research  Institute  (MBARI).  This  set  of  two  transceivers  run  on  12  volts,  provided  by  a 
120  volt  power  supply.  Each  Arlan  consists  of  the  following: 

•  The  Arlan  unit 

•  The  power  supply  (120  volt- 1 2  volt  adapter) 

•  Whip  antennal 

•  Yagi  antenna  and  cable 

The  units  accept  either  thick- wire  or  thin-wire  ethemet.  10Base2  Ethernet  (thin)  is 
connected  using  a  BNC  connector  with  a  50  ohm  terminator.  The  third  of  3  DIP  switches 
inside  each  unit  switches  between  thick-Eithemet  and  thin-wire  Ethernet  All  8  switches 
on  SW3  are  set  to  1  or  0,  depending  on  the  type  of  network  media  used.  Two  different 
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antennas  were  used:  omni-directional  whips  and  directional  yagis.  The  whips  were 
supplied  with  the  unit,  and  were  used  for  testing  and  for  use  within  a  building.  The  yagis 
were  used  outdoors,  and  provided  enough  gain  for  good  connectivity  over  a  range  of  about 
1  mile  through  two  groves  of  pine  trees,  which  was  surprising.  The  antennas  attach  to  the 
Arlan  via  coax  terminated  with  a  TNC  connector,  and  it  was  found  that  RG-303  MILSPEC 
cable  performed  the  best  when  compared  to  RG-58,  which  was  available  in  large  quantities. 
RG-303  was  not  available  in  large  quantities,  as  the  only  source  seemed  to  be  the 
Microwave  Lab  on  the  4th  floor  of  Spanagel  Hall.  The  actual  impedance  of  the  antenna 
cable  was  never  determined  but  was  probably  50  or  75  ohms.  Lengths  longer  than  50  feet 
are  not  recommended,  due  to  signal  attenuation. 

In  order  to  setup  the  Arlan  initially,  it  is  necessary  to  access  the  setup  program 
of  the  unit  using  the  DB-8  connector  positioned  in  the  bottom  of  the  case.  The  system  setup 
is  retained  in  flash  memory  chips  and  is  nonvolatile.  Plug  a  cable  with  a  male  DB-8 
connector  on  one  end  and  a  DB-9  or  DB-25  serial  connector  on  the  other  end  into  the  Arlan. 
Connect  the  other  end  to  either  a  serial  line  box  or  a  PC  which  has  the  software  to  run  a 
terminal  program.  Turn  on  the  serial  box,  or  start  a  terminal  program  on  the  PC,  and  set  the 
PC’s  terminal  setup  to  the  port  you  have  plugged  the  cable  into.  Ensure  the  cable  used  is  a 
null-modem  cable,  not  a  printer  cable.  Use  of  a  RS-232  Checker  (Light  Show)  makes  it 
easy  to  tell  if  you  have  the  wrong  cable-  simply  attach  the  light  show  to  the  Arlan  cable  and 
turn  it  on,  without  connecting  it  to  the  serial  box  or  PC.  Note  whether  or  not  TD  is  lit  Now 
secure  the  power  to  the  Arlan,  and  place  the  light  show  on  the  computer  or  tenninal  box, 
and  turn  it  on.  If  TD  is  lit  again,  you  need  a  null  modem  or  gender  changer  in  the  line 
between  the  two  units.  If  RTS  is  lit,  you  have  the  correct  cable  and  are  ready  to  continue. 
Turn  the  Arlan  off,  and  connect  the  cable  to  the  serial  box  or  PC,  then  turn  the  Arlan  back 
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on.  The  word  “connected”  should  appear.  Press  the  ENTER  key,  and  you  should 
immediately  see  Figure  D-2  on  the  serial  box  or  PC. 


Connected 

<TYPE  ENTER> 

ARLAN  620V2.01Beta 

Main  Menu  A620_000db7 

Option 

Value 

Description 

1  -  Statistics 

[  menu  ] 

-  Display  statistics 

2  -  Regtable 

[  menu  ] 

-  Registration  table  maintenance 

3  -  Logs 

[  menu  ] 

-  Alarm  and  log  control 

4  -  Privilege 

[  readonly 

]  -  Set  privilege  level 

5  -  Close 

-  Close  the  telnet  session 

6  -  Help 

-  Introduction 

Enter  an  option  number  or  name 

> 

Figure  D-2:  Initial  Telnet  Screen 

The  next  step  is  to  set  the  Privilege  level,  so  the  setup  menu  can  be  accessed.  Enter  the 
number  4  at  the  prompt,  and  push  ENTER.  The  next  screen  should  look  like  Figure  D-3. 


Enter  an  option  number  or  name 
>  privilege 

Enter  one  of  [off,  readonly,  write] :  w 


Figure  D-3:  Setting  write  permission. 

The  setup  program  will  then  display  a  prompt  for  the  password  to  be  entered.  The 
password  is  usually  known  by  the  last  person  to  use  the  Arlans,  and  is  also  known  by  Mr. 
Tom  Tengdin  at  the  Monterey  Bay  Aquarium  Research  Institute  (MBARI).  If  the  password 
is  unknown  or  cannot  be  correctly  entered,  the  next  method  is  to  reset  the  whole  unit  by  the 
following  procedure: 

•  Turn  the  unit  off. 

•  On  the  underside  of  the  unit,  loosen  the  two  phillips  head  screws  holding  the 


140 


rectangular  plate,  and  remove  the  plate.  Observe  3  DIP  switches:  2  close 
together,  and  one  set  apart  from  the  others  a  slight  amount.  Position  the  unit  so 
the  hole  with  the  switches  showing  is  up,  and  away  from  you.  The  DIP  switch  on 
the  left  is  SWl.On  the  middle  switch,  SW2,  set  7  and  8  to  both  1.  Both  switches 
should  already  be  set  to  0  for  console  port  control. 

•  Turn  the  power  back  on,  then  off  again. 

•  Reset  to  both  switches  back  to  0.  Turn  on.  The  unit  should  now  come  up  in  [write] 
mode  enabled  so  the  password  can  be  reset.  Please  make  a  note  of  the  password 
and  tape  it  into  the  case  so  the  next  person  does  not  have  to  do  this  same  exercise. 

All  the  options  displayed  in  the  brackets  [.]  need  only  to  have  the  first  letter  entered  at 
the  keyboard,  then  press  ENTER.  The  screen  shown  in  Figure  D-4  will  come  up. 


ARLAN  620  V2.01Beta 

Main  Menu  A620__000db2 

Option  Value 

Description 

1  -  Configuration 

[  menu 

]  -  General  configuration 

2  -  Statistics 

[  menu 

1  -  Display  statistics 

3  •  Regtable 

[  menu 

)  -  Registration  table  maintenance 

4  -  Logs 

[  menu 

]  -  Alarm  and  log  control 

5  •  Diagnostics 

[  menu 

)  -  Maintenance  and  testing  commands 

6  -  Privilege 

[  write  ] 

“  Set  privilege  level 

7  *  Close 

-  Close  the  telnet  session 

8  -  Help 

-  Introduction 

Enter  an  option  number  or  name 

> 

Figure  D-4:  Arlan  screen  after  entering  password. 
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The  most  important  screen  is  the  menu  following  selection  of  option  1  -  Configuration. 
This  screen  is  where  the  selection  is  made  to  modify  the  network  parameters,  identification, 
and  radio  settings.  The  screen  will  look  like  Figure  D-5. 


ARLAN  620  V2.01Beta  Configuration  Menu  A620_000db7 

Option  Value  Description 

1  -  Radio  [  menu  ]  -  Radio  network  parameters 

2  -  Ethernet  [  menu  ]  -  Ethernet  configuration 

3  -  Ident  [  menu  ]  -  Identification  information 

4  -  Console  [  menu  ]  -  Console  set-up 

5  -  Snmp  [  menu  ]  -  Set  snmp  values 

6  -  Dump  -  Dump  configuration  to  console 

Enter  an  option  number  or  name»  main  menu,  <ESC>  previous  menu 
> 


Figure  D-5:  Configuration  Menu. 
Entering  a  1  will  bring  up  Figure  D-6. 


Enter  an  option  number  or  name,  main  menu,  <ESC>  previous  menu 

>  radio 

ARLAN  620  V2.01Beta  Configuration  Radio  Menu  A620_000db7 

Option  Value  C>escription 

1  -  Sid  [  2  ]  -  System  identifier 

2  -  Bitrate  [  860  )  -  Data  bit  rate  in  kilobits  /  second 

3  -  Frequency  [  915.0  ]  -  Center  frequency  in  Mhz 

4  -  Channel  [11]-  Channel  number 

5 -  Root  [  on  ]  -  Enable  root  mode 

6  -  Linktest  [  menu  ]  -  Run  a  link  test 

7  -  Extended  [  menu  ]  -  Extended  parameters 

Enter  an  option  number  or  name,  "="  main  menu,  <ESC>  previous  menu 

> 


Figure  D-6:  Radio  Settings.  - 

The  setting  for  option  5  (Root)  is  different  for  the  other  Arlan  unit.  If  the  one  being  set 
has  root  mode  enabled,  the  other  unit  must  be  disabled,  or  “off.”  If  this  is  not  done,  the 
bridges  will  not  work.  The  other  options  can  all  be  set  as  before:  the  unit  will  display  the 
options  and  whichever  one  is  chosen  will  become  the  new  value.  However,  all  the  values 
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shown  work  well  for  whatever  applications  we  used  them  in.  Pressing  ESCAPE  will  bring 
back  the  original  menu  shown  in  Figure  D-5.  The  next  menu  is  Ethernet  and  is  shown  in 
Figure  D-7.  It  is  accessed  by  pressing  2. 


Enter  an  option  number  or  name,  main  menu,  <ESC>  previous  menu 

>  ethemet 

ARLAN  620  V2,01  Beta  Configuration  Ethemet  Menu  A620_000db7 

Option  Value  Description 

1  -  Active  [  on  ]  -  Ethemet  connection  active 

2  -  Size  [  1518  ]  -  Ethemet  maximum  frame  size 

Enter  an  option  number  or  name,  main  menu,  <ESC>  previous  menu 

> 


Figure  D-7:  Ethernet  Menu. 

Ensure  option  1  is  “on,”  else  the  Ethemet  packets  will  not  be  forwarded  although  the 
radios  link  up  and  communicate  between  each  other.  The  next  screen  is  most  important,  as 
the  IP  address  and  Subnet  mask  is  set  here.  Return  to  menu  shown  in  Figure  D-5  by  pressing 
ESCAPE  and  press  3  to  bring  up  the  Ident  menu.  The  screen  should  look  like  the  screen 
shown  in  Figure  D-8. 


Enter  an  option  number  or  name,  main  menu,  <ESC>  previous  menu 

>  Went 

ARLAN  620  V2.01  Beta  Configuration  Ident  Menu  A620_000db7 

Option  Value  Description 

1  -  Name  [  ’'A620_000db7”  ]  -  Node  name 

2  -  Nid  [  004096000db7 
3-Inaddr  [  131.120,063.131 

4  -  Inmask  [  255.255.255.000 

5  -  Location  [  **"  ] 

6 -Contact  [  ] 

7  -  Date  (  •’02/05/94  10:54*' 

Enter  an  option  number  or  name, 

> 


]  *  Network  address 

]  -  Internet  address  (YOUR  IP  ADDRESS  GOES  HERE) 
]  •  Internet  subnet  mask 

-  SNMP  system  location 

-  SNMP  system  contact  name 
-  Date  compiled 

"="  main  menu,  <ESC>  previous  menu 


Figure  D-8:  Indent  menu. 
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Options  1  and  2  should  not  be  modified.  Options  3  is  the  IP  address  which  should  be 
obtained  from  the  network  system  administrator,  and  must  be  a  unique  number.  IP 
addresses  cannot  be  shared.  The  first  16  bits  must  conform  to  the  domain,  and  the  3rd  set 
of  8  bits  must  identify  the  network.  The  last  8  bits  identifies  the  individual  node  on  the 
network.  For  some  networks,  the  Inmask  must  be  set  as  shown  above.  Not  doing  so  will 
prohibit  telnet  operation  from  outside  the  local  area  network.  The  other  fields  can  be  left 
blank.  Press  ESCAPE  to  return  to  the  screen  shown  in  Figure  4,  and  enter  a  4  in  order  to 
look  at  the  Console  settings  as  shown  next  in  Figure  D-9. 


Enter  an  option  number  or  name,  main  menu,  <ESC>  previous  menu 
>  console 


ARLAN  620  V2.01Beta  Configuration  Console  Menu  A620_000db7 

Option  Value  Description 

1  -  Type  [  teletype  ]  -  Terminal  type  (THIS  CAN  BE  SET  TO  ANSI,  ALSO) 

2  -  Rate  (  9600  ]  -  Console  baud  rate 

3  -  Bits  I  8  ]  -  Bits  per  character 

4  -  Parity  [  none  ]  -  Console  parity 

5  -  Autoconfigure  [  off  ]  -  Automatic  port  configuration 

6  -  Rpassword  -  Set  readonly  privilege  password 

7  -  Wpassword  -  Set  write  privilege  password  (DON’T  FORGET  THE  PASSWORD) 

8  -  Telnet  [  on  ]  •  Allow  telnet  connections 

Enter  an  option  number  or  name,  main  menu,  <ESC>  previous  menu 
> 


Figure  D-9:  Console  menu. 


Ensure  that  option  8  is  “on,”  else  the  Arlan  unit  will  not  allow  telnet  access,  and  all 
access  must  be  done  through  the  DIN-8  plug.  Finally,  press  ESCAPE  to  return  to  the 
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original  configuration  menu,  and  press  6  to  dump  the  entire  configuration  to  the  screen  for 
viewing.  It  should  look  like  Figure  D- 1 0. 


Enter  an  option  number  or  name,  main  menu,  <ESC>  previous  menu 
>  dump 

configuration  radio  sid  2 
configuration  radio  bitrate  860 
configuration  radio  frequency  915.0 
configuration  radio  root  on 
configuration  radio  extended  sidprefix  2 
configuration  radio  extended  Hdrsz  default 
configuration  ethemet  active  on 
configuration  ethemet  size  1518 
configuration  Ident  name  ’'A620_000db7‘' 
configuration  Idem  nid  004096000db7 
configuration  Ident  inaddr  131.120.063.131 
configuration  Ident  inmask  255.255.255.000 
configuration  Ident  location 
configuration  Ident  contact "" 
configuration  console  type  teletype 
configuration  console  rate  9600 
configuration  console  bits  8 
configuration  console  parity  none 
configuration  console  autoconfigure  off 
configuration  console  telnet  on 
configuration  snmp  enabled  off 
configuration  snmp  communities  add  public 
configuration  snmp  communities  add  proxy 
configuration  snmp  communities  add  private 
configuration  snmp  communities  add  regional 
configuration  snmp  communities  add  core 
configuration  snmp  trapdest  none 
configuration  snmp  trapcomm  "public" 
configuration  snmp  authtr^  off 
statistics  redisplay_time  10 
regtable  autoreg  on 
regtable  profile  bbnmcst  forward 
regtable  profile  radmcst  forward 
regtable  profile  bbndst  forward 
regtable  profile  raddst  forward 
regtable  profile  source  off 
logs  printlevel  error/severe 
logs  loglevel  all 
logs  led  level  error/severe 
logs  statuslock  off 
logs  extemlevel  off 
Hit  any  key  to  continue  ... 


Figure  D-10;  Arlan  screen  dump. 
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Little  else  needs  to  be  set  on  the  units.  Each  unit  when  turned  on  searches  for  the  other. 
The  middle  of  the  three  status  lights  on  the  top  of  the  unit  will  blink  green  continuously 
until  it  links  with  another  Arlan  which  is  set  to  the  opposite  Root  mode;  at  that  time  the  light 
will  change  to  steady  green.  Testing  can  be  done  using  the  whip  antennas,  or  no  antennas 
at  all,  if  the  Arlans  are  in  close  proximity  to  each  other.  Once  radio  sychronization  is 
achieved,  turn  the  units  off  and  connect  the  Ethernet  cable.  Do  not  forget  to  use  a 
T-connector  so  a  50  ohm  terminator  can  be  installed  if  the  bridge  is  the  end  of  the  network. 
Turn  the  units  back  on,  and  when  they  synch  up,  they  should  start  passing  data. 

2.  SOLECTEC  AIRLAN 

The  second  system  used  was  the  Solectek  AIRLAN/Bridge  Plus.  Like  the  Arlan,  this 
system  operates  in  the  9 1 5  Mhz  region,  but  this  system  is  capable  of  data  rates  of  2.0  Mbps, 
although  over  a  shorter  distance  than  the  6  miles  advertised  for  the  Arlans.  Three  miles  is 
the  advertised  range  with  a  YAGI  antenna,  two  of  which  were  ordered  with  the  units.  Power 
output  is  250  milliwatts,  using  Direct  Sequence  Spread  Spectrum  modulation.  Wireless 
media  access  control  protocol  is  CSMA/CA,  and  the  network  management  protocol  is 
SNMP/MIBn. 

Two  units  were  purchased  for  use  at  the  Interactive  3D  Graphics  Symposium,  and  are 
normally  in  operation  between  Spanagel  Hall  (CS  Graphics  Lab)  and  the  NPS  AUV 
Laboratory  at  the  Golf  Course.  The  Airlan  units  do  not  use  flash  memory  to  hold  their  setup 
data.  They  are  actually  IBM  compatible  386  computers  and  boot  their  configuration  from 
a  3.5”  floppy  disk.  The  configuration  file  is  setup  using  a  file  called  ABCONFIG.EXE 
which  runs  on  a  PC.  This  executable  file  reads  the  configuration  off  the  floppy  disk, 
displays  it,  and  allows  modification  of  the  data.  The  configuration  file  is  then  saved  back 
to  the  disk,  and  the  Airlan  unit  is  rebooted  by  turning  it  off  and  on  again.  Access  to  the 
Airlan  is  done  through  a  VGA  monitor  which  plugs  into  the  rear  of  the  unit,  just  like  a  PC. 
Power  is  provided  through  a  standard  120  volt  electrical  plug.  Unlike  the  Arlans,  which 
could  only  accept  thick  and  thin  Ethernet,  the  Airlans  will  accept  thick,  thin,  and  twisted 
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pair  Ethernet  media  (10Base2).  The  systems  have  a  BIOS  just  like  a  PC,  and  will  give  a 
keyboard  error  when  booting  up,  but  this  can  be  disregarded.  The  antenna  connection  is  for 
standard  cable  TV  cable,  RG-6,  and  each  unit  comes  supplied  with  two  lengths  of  cable  (15 
and  25  feet)  and  a  surge  arrester  for  lightening  protection.  The  antennae  supplied  are  a  small 
omnidirectional  for  use  inside  an  enclosed  room  or  building,  as  well  as  yagi  for  outdoor  use. 

Boot  diskettes  are  configured  as  follows.  Copy  the  file  ABCONFIG.EXE  to  a  directory 
in  a  PC  called  AIRLAN.  Put  the  diskette  from  the  Airlan  unit  in  the  PC’s  disk  drive  and 


switch  to  the  AIRLAN  directory.  Start  the  ABCONFIG.EXE  program  by  typing 
ABCONFIG  and  pressing  ENTER.  Press  ALT-F,  and  the  screen  in  Figure  D-1 1  should  be 
displayed.  When  the  program  starts,  you  want  to  import  the  configitfation  file  from  the 


Figure  D-11:  Airlan  Setup  Screen 


diskette,  so  type  “O”,  and  then  next  window  will  ask  for  the  file  name.  Type  the  name  of 
the  disk  drive  where  the  diskette  is  located,  such  as  “A:,”  then  press  ENTER.  The  program 
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will  search  for  files  with  a  “.BIN”  suffix,  and  display  them.  Move  the  highlighted  bar  down 
until  it  highlights  the  configuration  file  you  want  to  use  (usually  only  one)  and  press 
ENTER.  The  program  will  now  import  the  configuration,  and  you  will  see  the  screen  in 
Figure  D- 12. 


Figure  D-12:  Setting  IP  Address  in  Airlan  using  ABCONFIG.EXE. 

Operation  of  the  Airlan  units  are  essentially  the  same  as  the  Arlans  as  far  as  connection 
to  the  network  and  to  the  antenna  are  concerned.  The  antennae  are  attached  to  the  highest 
point  possible  for  the  cable  to  reach  and  pointed  at  each  other  (feed  point  to  the  rear, 
directors  laying  horizontally  active  elements  both  pointing  towards  the  same  compass 
direction)  and  connected  using  the  75  ohm  antenna  cable.  Connection  of  the  antenna  cable 
is  made  to  the  back  of  the  Airlan  on  the  connector  provided.  Attach  a  VGA  monitor  to  the 
unit  using  the  standard  video  plug  on  the  rear,  and  insert  a  configured  boot  diskette  in  the 
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will  search  for  files  with  a  “.BIN”  suffix,  and  display  them.  Move  the  highlighted  bar  down 
until  it  highlights  the  configuration  file  you  want  to  use  (usually  only  one)  and  press 

ENTER.  The  program  will  now  import  the  configuration,  and  you  wiU  see  the  screen  in 
Figure  D-12. 


Figure  D-12:  Setting  IP  Address  in  Airlan  using  ABCONFIG.EXE. 


Operation  of  the  Airlan  units  are  essentially  the  same  as  the  Arlans  as  far  as  connection 
to  the  network  and  to  the  antenna  are  concerned.  The  antennae  are  attached  to  the  highest 
point  possible  for  the  cable  to  reach  and  pointed  at  each  other  (feed  point  to  the  rear, 
directors  laying  horizontally  active  elements  both  pointing  towards  the  same  compass 
direction)  and  connected  using  the  75  ohm  antenna  cable.  Connection  of  the  antenna  cable 
IS  made  to  the  back  of  the  Airlan  on  the  connector  provided.  Attach  a  VGA  monitor  to  the 
unit  using  the  standard  video  plug  on  the  rear,  and  insert  a  configured  boot  diskette  in  the 
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APPENDIX  E;  RETRIEVING  THESIS  AND  SOURCE  CODE 

This  thesis  is  online  in  both  PostScipt  and  HTML  format  at  the  following  location: 
http:llwww.cs.nps.navy. mWresearchlauvIipoversw 

Source  code  used  in  the  thesis  is  also  available  at  the  above  address,  or  at  least  a 
symbolic  link  will  be  there  to  the  code. 

Promodem  code  is  available  from: 

Eutecnics 

do  Adrian  J.  Michaud  -  ProModem! 

30  Nagog  Pk.,  Suite  105 
Acton,  MA  01720 

Cost  is  $25.00,  and  purchase  price  includes  all  memory  models  with  source  code  and 
a  printed  manual.  Microsoft  C  and  Borland  Turbo  C  are  supported. 
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